Opened 6 months ago

Last modified 4 months ago

#14971 new bug

USB Ethernet adapter doesn't work anymore

Reported by: fotisk Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Drivers/USB/XHCI Version: R1/Development
Keywords: ethernet, TP-Link, gigabit Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86-64

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 6 months ago.
listdev.txt (1.7 KB ) - added by fotisk 6 months ago.
listusb.txt (959 bytes ) - added by fotisk 6 months ago.
syslog_wireless_working_hrev53001.txt (226.4 KB ) - added by fotisk 6 months ago.
syslog_usb_ecm_working_hrev52989.txt (499.6 KB ) - added by fotisk 6 months ago.
syslog_usb_ecm_on_USB3port_notworking_hrev53001.txt (176.1 KB ) - added by fotisk 6 months ago.
syslog_falling_after_connecting.txt (429.8 KB ) - added by tecchan 5 months ago.
syslog (336.2 KB ) - added by tecchan 5 months ago.
It did not work with Planex GU-1000T

Change History (19)

comment:1 by waddlesplash, 6 months ago

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

by fotisk, 6 months ago

Attachment: listdev.txt added

by fotisk, 6 months ago

Attachment: listusb.txt added

comment:2 by waddlesplash, 6 months 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, 6 months 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, 6 months 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.

comment:5 by waddlesplash, 6 months 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.

comment:6 by fotisk, 6 months 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, 6 months 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.

comment:8 by tecchan, 5 months ago

Syslog when falling after connecting USB-LAN

comment:9 by waddlesplash, 5 months 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 months ago

Attachment: syslog added

It did not work with Planex GU-1000T

comment:10 by waddlesplash, 5 months 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, 4 months ago

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

Note: See TracTickets for help on using tickets.