#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)
Change History (15)
by , 5 years ago
| Attachment: | listusb.txt added |
|---|
by , 5 years ago
| Attachment: | IMG_1451.HEIC added |
|---|
KDL when booting with device attached with hrev52992
by , 5 years ago
| Attachment: | IMG_1451.jpg added |
|---|
comment:1 by , 5 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 , 5 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:4 by , 5 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Another user reported on the forums that the KDL with USB-ECM devices is now gone.
comment:5 by , 5 years ago
by , 5 years ago
| Attachment: | syslog_TP-Link UE300_hrev53000 added |
|---|
comment:6 by , 5 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 , 5 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:9 by , 5 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 , 4 years ago
| Milestone: | Unscheduled → R1/beta2 |
|---|
Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone
Contents of listusb when device was working