USB Ethernet adapter doesn't work anymore

[fotisk]

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.

[waddlesplash]

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

[waddlesplash]

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.

[waddlesplash]

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

[fotisk]

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.

[waddlesplash]

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.

[fotisk]

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..

[waddlesplash]

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.

[tecchan]

Syslog when falling after connecting USB-LAN

[waddlesplash]

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.

[tecchan]

It did not work with Planex GU-1000T

[waddlesplash]

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.

[waddlesplash]

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

[waddlesplash]

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

[waddlesplash]

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.