Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Sep 2022 20:24:08 -0400
From:      Alexander Motin <mav@FreeBSD.org>
To:        Hans Petter Selasky <hps@selasky.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:  <bc90f83d-511d-d31f-d9f7-0aaf82ecba4a@FreeBSD.org>
In-Reply-To: <1f11b131-7031-60db-4331-d95159c5b373@selasky.org>
References:  <CP6P284MB1900F16EDAEAF1CB485BC372CB499@CP6P284MB1900.BRAP284.PROD.OUTLOOK.COM> <de8c944a-59b7-1fb0-e8bf-0f4c31d95090@selasky.org> <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>

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

-- 
Alexander Motin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bc90f83d-511d-d31f-d9f7-0aaf82ecba4a>