Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Sep 2022 08:54:12 -0300 (-03)
From:      Ivan Quitschal <tezeka@hotmail.com>
To:        Hans Petter Selasky <hps@selasky.org>
Cc:        Ivan Quitschal <tezeka@hotmail.com>, 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:  <CP6P284MB19002951FC5F6595F1621EFFCB549@CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM>
In-Reply-To: <ae4e53f9-e378-a50b-1a6c-daf6a6644db1@selasky.org>
References:  <CP6P284MB1900F16EDAEAF1CB485BC372CB499@CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM> <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> <ae4e53f9-e378-a50b-1a6c-daf6a6644db1@selasky.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--3432851520-1700655352-1664366053=:1776
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT



On Wed, 28 Sep 2022, Hans Petter Selasky wrote:

> 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&amp;data=05%7C01%7C%7Cc2f534f631fd47afec9908daa135d60b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637999549868812246%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=uL5DwbPcldediZmBiufQXnkF7%2F2WQTizqVLAYBHZjqA%3D&amp;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
>


hi Hans

i will try to do some logs filtered like you said , and will also try to 
compress as much as i want the full ones. ( i may be able to transform 150M into 
no more than 10M, its all plain text)

i will send you here and the list as soon as i do this .. dont know if ill be 
able to do this today, but tomorrow you'll get the full logs even if i have to 
open the ftp for you myself :- )


thanks

--tzk

--3432851520-1700655352-1664366053=:1776--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CP6P284MB19002951FC5F6595F1621EFFCB549>