From nobody Tue Sep 27 13:22:50 2022 X-Original-To: freebsd-current@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 4McL0Q5nXSz4d0P2; Tue, 27 Sep 2022 13:23:02 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4McL0P66r0z3SMw; Tue, 27 Sep 2022 13:23:01 +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 B5418260160; Tue, 27 Sep 2022 15:22:53 +0200 (CEST) Message-ID: <93745237-5a3c-b81b-36d3-3c883bc4f2d3@selasky.org> Date: Tue, 27 Sep 2022 15:22:50 +0200 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@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 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> Content-Language: en-US From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4McL0P66r0z3SMw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-3.21 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.91)[-0.905]; 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:88.99.0.0/16, 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 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