Date: Wed, 28 Sep 2022 11:42:58 +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: <ae4e53f9-e378-a50b-1a6c-daf6a6644db1@selasky.org> In-Reply-To: <CP6P284MB1900D9AC281479C696897680CB549@CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM> References: <CP6P284MB1900F16EDAEAF1CB485BC372CB499@CP6P284MB1900.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> <93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org> <37d15b0a-0cc1-0830-98a9-c7e19b7a7ef5@selasky.org> <CP6P284MB1900D9AC281479C696897680CB549@CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9/28/22 11:07, Ivan Quitschal wrote:
>
>
> On Tue, 27 Sep 2022, Hans Petter Selasky wrote:
>
>> On 9/27/22 15:22, Hans Petter Selasky wrote:
>>> 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
>>>
>>
>> FYI: There is some experimental thunderbolt support at:
>>
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fhselasky%2Fusb4&data=05%7C01%7C%7C14c86eee9f5d492c41d508daa0b49bdb%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637998994857157968%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FOnIO3esoAmi1FSPkHRYpHCHkcN6U2rO9WhaimdaVbk%3D&reserved=0
>>
>> But I'm not sure if it supports the hardware you've got.
>>
>> --HPS
>>
>
>
> Hi Hans
>
> i got two log versions for you, one with the constant set to 2048 (the
> working version) , and the other with no patches whatsoever (the bad
> version)
>
> since the entire logs reached more than 150M of size, i had to cut to
> the last 1000 lines , hope toats enough
>
> pleaes find attached the two files
>
> the xhci_NOT_working i stoped recording right after the problem ocurred
>
> please let me know if you need something else
>
> thank you
>
> --tzk
I need the full log.
The XHCI driver is very verbose you see.
Maybe you can do some filtering, like figuring out all the status codes
you see:
status=1
status=13
and so on.
--HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ae4e53f9-e378-a50b-1a6c-daf6a6644db1>