Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#14959 closed bug (fixed)

USB Ethernet adapter causing KDL

Reported by: mrentropy Owned by: nobody
Priority: normal Milestone: R1/beta2
Component: Drivers/USB/XHCI Version: R1/Development
Keywords: ethernet, insignia, gigabit Cc:
Blocked By: Blocking:
Platform: x86-64

Description

Device: Insignia USB 3.0 to Gigabit Ethernet Adapter Model No: NS-PU98635/NS-PU98635-C

Was working plugged into a USB2 port with hrev52947 x86_64

After updating to hrev52992, booting with the device plugged into USB2 or USB3 caused Haiku to enter KDL. Plugging device into a USB2 port when Haiku was fully booted also caused KDL.

Attachments (5)

listusb.txt (882 bytes ) - added by mrentropy 6 years ago.
Contents of listusb when device was working
syslog (160.5 KB ) - added by mrentropy 6 years ago.
Syslog from when device was working hrev52947
IMG_1451.HEIC (1.7 MB ) - added by mrentropy 6 years ago.
KDL when booting with device attached with hrev52992
IMG_1451.jpg (1.5 MB ) - added by waddlesplash 6 years ago.
syslog_TP-Link UE300_hrev53000 (483.9 KB ) - added by fotisk 6 years ago.

Change History (15)

by mrentropy, 6 years ago

Attachment: listusb.txt added

Contents of listusb when device was working

by mrentropy, 6 years ago

Attachment: syslog added

Syslog from when device was working hrev52947

by mrentropy, 6 years ago

Attachment: IMG_1451.HEIC added

KDL when booting with device attached with hrev52992

by waddlesplash, 6 years ago

Attachment: IMG_1451.jpg added

comment:1 by waddlesplash, 6 years ago

Please attach a more commonly readable file format, next time...

At any rate, this has little to do with USB network drivers, it appears I just messed up lock order somehow.

comment:2 by waddlesplash, 6 years ago

So, I really don't understand how I messed this up, the code looks perfectly fine to me. We lock the lock once at the top of the function; there is no way for mutex_lock to fail in KDEBUG mode (that I can tell), and then there is only one way out at the bottom, and we unlock the mutex there. How does this lead to a double-unlock?

comment:3 by waddlesplash, 6 years ago

Please retest after hrev52997.

comment:4 by waddlesplash, 6 years ago

Resolution: fixed
Status: newclosed

Another user reported on the forums that the KDL with USB-ECM devices is now gone.

comment:5 by fotisk, 6 years ago

My usb_to_ethernet adapter doesn't work anymore in hrev53000. Stays in "Configuring.." state. Was fully working on hrev52989. TP-Link UE300 (USB 3.0 to Gigabit). I attach my syslog in case it helps. I hope I am commenting on the right tcket, sorry if not.

Last edited 6 years ago by fotisk (previous) (diff)

by fotisk, 6 years ago

comment:6 by waddlesplash, 6 years ago

Please open a new ticket. It seems that your device is continually resetting. Can you try it on a USB2 port?

comment:7 by mrentropy, 6 years ago

The KDLs have, indeed, stopped. However, the device no longer works. It shows up and has a MAC address, but syslog shows a lot of send/requests to the DHCP server with the occasional "unsupported ioctl 8925" message.'

I'm guessing you'll want a new ticket for that and close this one?

comment:8 by waddlesplash, 6 years ago

Yes. As said before, please try it on a USB2 port also.

comment:9 by fotisk, 6 years ago

My device (TP-Link) is connected to a USB2 port through an external USB2 hub. The exact same configuration that works when I boot to hrev52989. I will try to test it with direct connection also and not through the hub to see if something changes. Will create a new ticket unless mrentropy creates it first.

comment:10 by nielx, 5 years ago

Milestone: UnscheduledR1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

Note: See TracTickets for help on using tickets.