Opened 5 years ago

Closed 3 years ago

#14971 closed bug (fixed)

USB Ethernet adapter doesn't work anymore

Reported by: fotisk Owned by: waddlesplash
Priority: normal Milestone: R1/beta4
Component: Drivers/USB/XHCI Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Device: TP-Link UE300 (USB 3.0 to Gigabit).

Doesn't work anymore in hrev53000. Stays in "Configuring.." state. Was fully working on hrev52989 connected to a USB 2 port (directly or indirectly through an external USB 2 hub). Attached my syslog.

Attachments (8)

syslog_TP-Link UE300_hrev53000.txt​ (483.9 KB ) - added by fotisk 5 years ago.
listdev.txt​ (1.7 KB ) - added by fotisk 5 years ago.
listusb.txt​ (959 bytes ) - added by fotisk 5 years ago.
syslog_wireless_working_hrev53001.txt​ (226.4 KB ) - added by fotisk 5 years ago.
syslog_usb_ecm_working_hrev52989.txt​ (499.6 KB ) - added by fotisk 5 years ago.
syslog_usb_ecm_on_USB3port_notworking_hrev53001.txt​ (176.1 KB ) - added by fotisk 5 years ago.
syslog_falling_after_connecting.txt​ (429.8 KB ) - added by tecchan 5 years ago.
syslog​ (336.2 KB ) - added by tecchan 5 years ago.
It did not work with Planex GU-1000T

Change History (21)

by fotisk, 5 years ago

Attachment: syslog_TP-Link UE300_hrev53000.txt​ added

comment:1 by waddlesplash, 5 years ago

It seems your syslog does not include device info. Please attach the outputs of listdev and listusb as text files also.

by fotisk, 5 years ago

Attachment: listdev.txt​ added

by fotisk, 5 years ago

Attachment: listusb.txt​ added

comment:2 by waddlesplash, 5 years ago

The only major XHCI change in that range is ​1d79fe616f, which makes CancelQueuedTransfers actually more than a no-op.

However, if we are getting "new device on a port that is already in use", it's possible that something strange is happening at the stack level. Can I get 2 more syslogs from you, please (in addition to what I already requested above):

  1. One from when it was working
  2. One from it plugged into a USB3.0 port.

Even this may not be enough; I may need to acquire a USB-ECM 3.0 device myself to try and test.

comment:3 by waddlesplash, 5 years ago

OK, thanks for those. Pertinent information: 

device Serial bus controller (USB controller, XHCI) [c|3|30]
  vendor 8086: Intel Corporation
  device 9c31: 8 Series USB xHCI HC

2357:0601 /dev/bus/usb/0/0/3 "TP-Link" "USB 10/100/1000 LAN" ver. 3000

comment:4 by fotisk, 5 years ago

I will add the 2 new syslogs probably tomorrow.

Another remark which I don't know if has any relation but to give you the big picture: my wireless began working today without having done something special. During testing the USB-ECM with various ports to see what is happening, somehow wireless began working. But not all times. It seems more probable to work when I have attached things in USB 2 port..

Right now though it works with my usual configuration on hrev53001: external USB 2 hub which has USB-ECM connected (not working) and an Apple keyboard (to which I have a mouse connected). I am attaching my current syslog.

by fotisk, 5 years ago

Attachment: syslog_wireless_working_hrev53001.txt​ added

comment:5 by waddlesplash, 5 years ago

Probably that is a fluke. The "idualwifi7260" driver is very flaky even on my hardware; half the time it works, half the time it does not. I guarantee it worked for you before too, you just need to disable/re-enable the device inbetween connection attempts, and eventually it will work.

by fotisk, 5 years ago

Attachment: syslog_usb_ecm_working_hrev52989.txt​ added

by fotisk, 5 years ago

Attachment: syslog_usb_ecm_on_USB3port_notworking_hrev53001.txt​ added

comment:6 by fotisk, 5 years ago

Just attached the 2 syslogs you asked.

You are right about the wireless. I remember that it worked once in hrev52989 but couldn't reproduce the success.. Right now in hrev53001 it didn't work on boot but after some disable/enable attempts it worked; thanks for the hint :) The thing is that after it works it seems pretty stable..

comment:7 by waddlesplash, 5 years ago

Yep, there are still a massive amount of "new device on a port that is already in use" in the working syslog. So my commit is still correct it appears, it's just that we trigger a lot of spurious port resets, which is very strange.

by tecchan, 5 years ago

Attachment: syslog_falling_after_connecting.txt​ added

comment:8 by tecchan, 5 years ago

Syslog when falling after connecting USB-LAN

comment:9 by waddlesplash, 5 years ago

Actually that syslog appears to be a different problem: 

KERN: usb error xhci 0: TRB 0x8d9200 was not found in the endpoint!

It's possible these two have the same root cause, however.

by tecchan, 5 years ago

Attachment: syslog​ added

It did not work with Planex GU-1000T

comment:10 by waddlesplash, 5 years ago 

96	KERN: [33musb_asix:[0m02.04.160:Read::Error of queue_bulk_v request:0x80000000
97	KERN: PMA: bad value for allocate (41231686064 bytes)
98	KERN: usb error xhci 0: KERN: failed to allocate TRBs

This is a different bug; please open a new ticket for it.

comment:11 by waddlesplash, 5 years ago

hrev53137 may improve or even outright fix this ticket; so please retest.

comment:12 by waddlesplash, 3 years ago

Keywords: ethernet TP-Link gigabit removed
Owner: changed from nobody to waddlesplash
Platform: x86-64 → All
Status: new → assigned

Turns out this is reproducible under QEMU. So, that makes it much easier to investigate.

comment:13 by waddlesplash, 3 years ago

Milestone: Unscheduled → R1/beta4
Resolution: → fixed
Status: assigned → closed

In addition to the bugs in our XHCI driver, there was also a QEMU bug that got in the way of this working, which I have reported upstream (there is already a fix for it, but it got lost): ​https://gitlab.com/qemu-project/qemu/-/issues/593

Fixed in hrev55376.

Note: See TracTickets for help on using tickets.