From nobody Tue Sep 27 18:17:54 2022 X-Original-To: freebsd-usb@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4McSXn3Sn7z4YMZ7; Tue, 27 Sep 2022 18:18:01 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4McSXm2lRdz41KZ; Tue, 27 Sep 2022 18:18:00 +0000 (UTC) (envelope-from hps@selasky.org) Received: from [10.36.2.155] (unknown [178.232.223.95]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id DA307260160; Tue, 27 Sep 2022 20:17:57 +0200 (CEST) Message-ID: <37d15b0a-0cc1-0830-98a9-c7e19b7a7ef5@selasky.org> Date: Tue, 27 Sep 2022 20:17:54 +0200 List-Id: FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-usb List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-usb@freebsd.org X-BeenThere: freebsd-usb@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0 Subject: Re: RES: TP-LINK USB no carrier after speed test From: Hans Petter Selasky To: Ivan Quitschal Cc: Alexander Motin , "freebsd-current@freebsd.org" , "freebsd-usb@FreeBSD.org" References: <5f646a9a-2885-05af-9ff1-ef4c4446f365@selasky.org> <9c370afb-1931-f977-16a9-4915a82ec773@selasky.org> <5bf98c30-c00f-7e7a-3a3d-c0bd5862fb97@selasky.org> <1f11b131-7031-60db-4331-d95159c5b373@selasky.org> <4f8778a0-0c47-ff47-f954-ba4e8d9fc5e1@selasky.org> <93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org> Content-Language: en-US In-Reply-To: <93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4McSXm2lRdz41KZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.26 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.96)[-0.964]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org,freebsd-usb@FreeBSD.org]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_TO(0.00)[hotmail.com]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[selasky.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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 >>> 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: 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: at usbus0, cfg=0 md=HOST >> spd=SUPER (5.0Gbps) pwr=ON (72mA) >> ugen0.10: at usbus0, cfg=0 md=HOST >> spd=SUPER (5.0Gbps) pwr=ON (72mA) >> >>    bLength = 0x0012 >>    bDescriptorType = 0x0001 >>    bcdUSB = 0x0300 >>    bDeviceClass = 0x0000  >>    bDeviceSubClass = 0x0000 >>    bDeviceProtocol = 0x0000 >>    bMaxPacketSize0 = 0x0009 >>    idVendor = 0x2357 >>    idProduct = 0x0601 >>    bcdDevice = 0x3000 >> **** >>    iManufacturer = 0x0001  >>    iProduct = 0x0002  >>    iSerialNumber = 0x0006  <000001> >>    bNumConfigurations = 0x0002 >> >> ------------------------ >> >> after the problem >> >> -------------------------- >> ugen0.10: at usbus0, cfg=0 md=HOST >> spd=SUPER (5.0Gbps) pwr=ON (72mA) >> ugen0.10: at usbus0, cfg=0 md=HOST >> spd=SUPER (5.0Gbps) pwr=ON (72mA) >> >>    bLength = 0x0012 >>    bDescriptorType = 0x0001 >>    bcdUSB = 0x0300 >>    bDeviceClass = 0x0000  >>    bDeviceSubClass = 0x0000 >>    bDeviceProtocol = 0x0000 >>    bMaxPacketSize0 = 0x0009 >>    idVendor = 0x2357 >>    idProduct = 0x0601 >>    bcdDevice = 0x3000 >> **** >> iManufacturer = 0x0001  >>    iProduct = 0x0002  >>    iSerialNumber = 0x0006  >>    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: 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: 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://github.com/hselasky/usb4 But I'm not sure if it supports the hardware you've got. --HPS