Date: Tue, 27 Sep 2022 15:22:50 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Ivan Quitschal <tezeka@hotmail.com> Cc: Alexander Motin <mav@FreeBSD.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>, "freebsd-usb@FreeBSD.org" <freebsd-usb@FreeBSD.org> Subject: Re: RES: TP-LINK USB no carrier after speed test Message-ID: <93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org> In-Reply-To: <CP6P284MB19006894C8DA481BD73A3F1BCB559@CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM> References: <CP6P284MB1900F16EDAEAF1CB485BC372CB499@CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM> <CP5P284MB1902026EB918E88DE5581ACCCB489@CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM> <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org> <CP5P284MB1902929145200C5BE706C789CB489@CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM> <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org> <CP5P284MB19020B7054012F9140E9D8F2CB489@CP5P284MB1902.BRAP284.PROD.OUTLOOK.COM> <CP6P284MB19005F8AF0CF964D011E8EA7CB4A9@CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM> <fd261e3f-ed98-1c48-2af2-943520acbf13@selasky.org> <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org> <CP6P284MB1900A6E8ECDB4CFF78323904CB529@CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM> <d863a8ec-edfd-73bc-c772-216830e0d7d5@FreeBSD.org> <1f11b131-7031-60db-4331-d95159c5b373@selasky.org> <bc90f83d-511d-d31f-d9f7-0aaf82ecba4a@FreeBSD.org> <4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org> <CP6P284MB19006894C8DA481BD73A3F1BCB559@CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/27/22 14:17, Ivan Quitschal wrote:
>
>
> On Tue, 27 Sep 2022, Hans Petter Selasky wrote:
>
>> On 9/27/22 02:24, Alexander Motin wrote:
>>> On 26.09.2022 17:29, Hans Petter Selasky wrote:
>>>> I've got a supposedly "broken" if_ure dongle from Alexander, but I'm
>>>> unable to reproduce the if_ure hang on two different pieces of XHCI
>>>> hardware, Intel based and AMD based, which I've got.
>>>>
>>>> This leads me to believe there is a bug in the XHCI driver or
>>>> hardware on your system.
>>>>
>>>> Can you share the pciconfig -lv output for your XHCI controllers?
>>>
>>> I have two laptops of different generations reproducing this problem,
>>> but both are having Thunderbolt on the USB-C ports:
>>>
>>> This is one (7th Gen Core i7):
>>>
>>> xhci1@pci0:56:0:0: class=0x0c0330 rev=0x02 hdr=0x00
>>> vendor=0x8086 device=0x15d4 subvendor=0x2222 subdevice=0x1111
>>> vendor = 'Intel Corporation'
>>> device = 'JHL6540 Thunderbolt 3 USB Controller (C step)
>>> [Alpine Ridge 4C 2016]'
>>> class = serial bus
>>> subclass = USB
>>> bar [10] = type Memory, range 32, base 0xc3f00000, size 65536,
>>> enabled
>>> cap 01[80] = powerspec 3 supports D0 D1 D2 D3 current D0
>>> cap 05[88] = MSI supports 8 messages, 64 bit enabled with 1 message
>>> cap 10[c0] = PCI-Express 2 endpoint max data 128(128) RO NS
>>> max read 512
>>> link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1)
>>> ClockPM disabled
>>> ecap 0003[100] = Serial 1 20ff910876f10c00
>>> ecap 0001[200] = AER 1 0 fatal 0 non-fatal 1 corrected
>>> ecap 0002[300] = VC 1 max VC0
>>> ecap 0004[400] = Power Budgeting 1
>>> ecap 000b[500] = Vendor [1] ID 1234 Rev 1 Length 216
>>> ecap 0018[600] = LTR 1
>>> ecap 0019[700] = PCIe Sec 1 lane errors 0
>>>
>>> This is another (11th Gen Core i7);
>>>
>>> xhci0@pci0:0:13:0: class=0x0c0330 rev=0x01 hdr=0x00
>>> vendor=0x8086 device=0x9a13 subvendor=0x1028 subdevice=0x0991
>>> vendor = 'Intel Corporation'
>>> device = 'Tiger Lake-LP Thunderbolt 4 USB Controller'
>>> class = serial bus
>>> subclass = USB
>>> bar [10] = type Memory, range 64, base 0x60552c0000, size
>>> 65536, enabled
>>> cap 01[70] = powerspec 2 supports D0 D3 current D0
>>> cap 05[80] = MSI supports 8 messages, 64 bit enabled with 1 message
>>> cap 09[90] = vendor (length 20) Intel cap 15 version 0
>>> cap 09[b0] = vendor (length 0) Intel cap 0 version 1
>>>
>>> Does the system you also has Thunderbolt chip, or you use native
>>> Intel chipet's XHCI?
>>>
>>>> Also, when running the stress test and you see the traffic stops,
>>>> what happens if you run this command as root on the ugen which the
>>>> if_ure belongs to:
>>>>
>>>> usbconfig -d ugenX.Y dump_string 0
>>>>
>>>> Does the traffic resume?
>>>
>>> Nope. Out of 4 times when traffic stopped 2 times it reported <read
>>> error> and 2 times it completed successfully, but it neither case it
>>> recovered traffic. Only reset recovered it.
>>>
>>
>> Hi Alexander,
>>
>> Could you run "usbdump -d X.Y" at the same time to capture all the
>> errors?
>>
>> Looking especially for USB_ERR_TIMEOUT .
>>
>> I have this:
>>
>> xhci0@pci0:3:0:3: class=0x0c0330 rev=0x00 hdr=0x00 vendor=0x1022
>> device=0x15e0 subvendor=0x1849 subdevice=0xffff
>> vendor = 'Advanced Micro Devices, Inc. [AMD]'
>> device = 'Raven USB 3.1'
>> class = serial bus
>> subclass = USB
>>
>> xhci0@pci0:0:20:0: class=0x0c0330 rev=0x21 hdr=0x00 vendor=0x8086
>> device=0x9d2f subvendor=0x8086 subdevice=0x9d2f
>> vendor = 'Intel Corporation'
>> device = 'Sunrise Point-LP USB 3.0 xHCI Controller'
>> class = serial bus
>> subclass = USB
>>
>> --HPS
>>
>
>
> hi Hans
>
> i think i got some good logs for you
>
> before the problem i ran this:
>
> ugen0.10: <TP-Link USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>
> # usbconfig -d ugen0.10 >> before
> # usbconfig -d ugen0.10 dump_all_desc >> before
> # usbconfig -d ugen0.10 dump_stats >> before_status
>
> the after the problem happened i ran
>
> # usbconfig -d ugen0.10 >> after
> # usbconfig -d ugen0.10 dump_all_desc >> after
> # usbconfig -d ugen0.10 dump_stats >> after_status
>
>
> just by looking i already see some problems comparing both
>
> for example
>
> before the problem we have:
>
> ----------------------
> ugen0.10: <TP-Link USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
> ugen0.10: <TP-Link USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>
> bLength = 0x0012
> bDescriptorType = 0x0001
> bcdUSB = 0x0300
> bDeviceClass = 0x0000 <Probed by interface class>
> bDeviceSubClass = 0x0000
> bDeviceProtocol = 0x0000
> bMaxPacketSize0 = 0x0009
> idVendor = 0x2357
> idProduct = 0x0601
> bcdDevice = 0x3000
> ****
> iManufacturer = 0x0001 <TP-Link>
> iProduct = 0x0002 <USB 10/100/1000 LAN>
> iSerialNumber = 0x0006 <000001>
> bNumConfigurations = 0x0002
>
> ------------------------
>
> after the problem
>
> --------------------------
> ugen0.10: <TP-Link USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
> ugen0.10: <TP-Link USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>
> bLength = 0x0012
> bDescriptorType = 0x0001
> bcdUSB = 0x0300
> bDeviceClass = 0x0000 <Probed by interface class>
> bDeviceSubClass = 0x0000
> bDeviceProtocol = 0x0000
> bMaxPacketSize0 = 0x0009
> idVendor = 0x2357
> idProduct = 0x0601
> bcdDevice = 0x3000
> ****
> iManufacturer = 0x0001 <retrieving string failed>
> iProduct = 0x0002 <retrieving string failed>
> iSerialNumber = 0x0006 <retrieving string failed>
> bNumConfigurations = 0x0002
>
> Configuration index 0 --------------------------
>
>
> the log in ttyv0 was this:
>
> ure0: at uhub0, port 14, addr 9 (disconnected)
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: receive_packet failed on
> ue0: Device not configured
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: ioctl(SIOCGIFFLAGS) on ue0:
> Operation not permitted
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: Interface ue0 no longer
> appears valid.
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: No live interfaces to poll
> on - exiting.
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: exiting.
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: connection closed
> Sep 27 08:55:58 tzk-inspiron dhclient[1201]: exiting.
> rgephy0: detached
> miibus0: detached
> ure0: detached
>
>
> difference between before_status and after_status
>
> before_status:
>
> ugen0.10: <TP-Link USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>
> {
> UE_CONTROL_OK : 2389
> UE_ISOCHRONOUS_OK : 0
> UE_BULK_OK : 803
> UE_INTERRUPT_OK : 0
> UE_CONTROL_FAIL : 0
> UE_ISOCHRONOUS_FAIL : 0
> UE_BULK_FAIL : 0
> UE_INTERRUPT_FAIL : 0
> }
>
>
> after_status:
>
> ugen0.10: <TP-Link USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST
> spd=SUPER (5.0Gbps) pwr=ON (72mA)
>
> {
> UE_CONTROL_OK : 4275
> UE_ISOCHRONOUS_OK : 0
> UE_BULK_OK : 1126702
> UE_INTERRUPT_OK : 0
> UE_CONTROL_FAIL : 326
> UE_ISOCHRONOUS_FAIL : 0
> UE_BULK_FAIL : 42
> UE_INTERRUPT_FAIL : 0
> }
>
>
>
> i hope that helps
>
>
> all log files are attached
>
> thanks
>
> --tzk
One more test request:
Make sure you have a kernel with "options USB_DEBUG".
Then after "iperf" says 0bits/s, then you run:
sysctl hw.usb.xhci.debug=29
Then run those usbconfig commands.
Then then:
sysctl hw.usb.xhci.debug=0
And collect the logs from /var/log/messages .
Like said earlier, I wonder if the fault is in the XHCI controller
itself or something that has to do with thunderbolt, because on my
machine there is no indication of a if_ure device failure. The only way
to know for sure is to buy a USB 3.0 wire analyzer, like the beagle one,
but I'm unsure if they support USB-C .
Thank you!
--HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?93745237-5a3c-b81b-36d3-3c883bc4f2d3>