Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Sep 2022 09:19:00 +0200
From:      Hans Petter Selasky <hps@selasky.org>
To:        Alexander Motin <mav@FreeBSD.org>, Ivan Quitschal <tezeka@hotmail.com>
Cc:        "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:  <4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org>
In-Reply-To: <bc90f83d-511d-d31f-d9f7-0aaf82ecba4a@FreeBSD.org>
References:  <CP6P284MB1900F16EDAEAF1CB485BC372CB499@CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM> <5c9c47d6-9e12-ae76-ce67-15aeae1b8636@selasky.org> <11b7de01-d95e-5280-2a22-8b17e29c34c0@selasky.org> <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>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1>