Spinning out as a new thread since it's this is a somewhat different topic.
A few years ago I was running into weird problems with USB attached storage so I did some research into the USB stack for linux. Not a huge amount, just needed some context to explain why USB devices are so damn unreliable. Turns out, in the Linux XHCI driver there is a thing called "quirks". Quirks are specific fixes or workarounds for host controllers that behave in a way that is either incorrect or a blind spot in the USB specification. Here's the link again to the comments related to the HP ZXXX workstations https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/usb/host/xhci.c?h=v6.6.60#n366 There are other comments in that file that reference other controllers. e.g. there's one for Intel that mentions a 1 mS timer when performing a reset that may not be present on non-Intel chips.. Turns out, these quirks are pretty common and you can check dmesg to see if any have been implemented for your hardware. My desktop appears to use a renesas HC root# lsmod |grep xhci xhci_pci 24576 0 xhci_pci_renesas 12288 1 xhci_pci xhci_hcd 344064 1 xhci_pci root# modinfo xhci_hcd filename: /lib/modules/6.10.14/kernel/drivers/usb/host/xhci-hcd.ko license: GPL author: Sarah Sharp description: 'eXtensible' Host Controller (xHC) Driver depends: retpoline: Y intree: Y name: xhci_hcd vermagic: 6.10.14 SMP preempt mod_unload parm: link_quirk:Don't clear the chain bit on a link TRB (int) parm: quirks:Bit flags for quirks to be enabled as default (ullong) You could actually specify which quirks you want enabled when the xhci_hcd module loads. You can also grep dmesg to see if any quirks were autodetected. Here are the quirks detected for my renesas chip # dmesg |grep quirk [ 5.791222] xhci_hcd 0000:0f:00.0: hcc params 0x0200ef81 hci version 0x110 quirks 0x0000000200000010 [ 5.851546] xhci_hcd 0000:11:00.0: hcc params 0x0200ef81 hci version 0x110 quirks 0x0000000200000010 [ 5.856313] xhci_hcd 0000:13:00.3: hcc params 0x0120ffc5 hci version 0x120 quirks 0x0000000200000010 [ 5.858161] xhci_hcd 0000:13:00.4: hcc params 0x0120ffc5 hci version 0x120 quirks 0x0000000200000010 [ 5.861445] xhci_hcd 0000:14:00.0: hcc params 0x0110ffc5 hci version 0x120 quirks 0x0000000200000010 You'd have to do some research into the particulars of your HC, but if you are having persistent issues specific to a certain hardware configuration you can check to see if there are known quirks. These quirks can be manually specified if autodetection fails. You might also be able to fiddle with things like power management to mitigate problems on more advanced host controllers. This also provides some context since these are cheap tricks that only mitigate the problem. For something like the HP Z series you will occasionally hit a 2second timer where you simply have to wait for the ports to become active again. Food for thought when dealing with USB nonsense. -Ben On Saturday, November 9th, 2024 at 9:31 PM, Russell Senior <[email protected]> wrote: > Oh the Z820, with nothing plugged in, they just "aren't there". For example: > > lspci | grep -i usb > 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 > Enhanced Host Controller #2 (rev 05) > 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 > Enhanced Host Controller #1 (rev 05) > 03:00.0 USB controller: ASMedia Technology Inc. ASM2142 USB 3.1 Host > Controller > > The ASMedia is the PCIe card I plugged in. Whatever the C800/X79 xhci > devices are, they don't seem to show up in lscpi. > > Otoh, dmidecode gives me: > > Handle 0x001C, DMI type 8, 9 bytes > Port Connector Information > Internal Reference Designator: J12 1394 > Internal Connector Type: None > External Reference Designator: Rear USB 3.0(1) > External Connector Type: Access Bus (USB) > Port Type: USB > > Handle 0x001D, DMI type 8, 9 bytes > Port Connector Information > Internal Reference Designator: J12 1394 > Internal Connector Type: None > External Reference Designator: Rear USB 3.0(2) > External Connector Type: Access Bus (USB) > Port Type: USB > > and > > Handle 0x0022, DMI type 8, 9 bytes > Port Connector Information > Internal Reference Designator: P29 I-USB3 (3) > Internal Connector Type: Access Bus (USB) > External Reference Designator: Not Specified > External Connector Type: None > Port Type: USB > > Handle 0x0023, DMI type 8, 9 bytes > Port Connector Information > Internal Reference Designator: P29 I-USB3 (4) > Internal Connector Type: Access Bus (USB) > External Reference Designator: Not Specified > External Connector Type: None > Port Type: USB > > The top pair look like they are talking about the USB3 ports on the > rear of the chassis. The second pair, I am not sure how to read. > > On Sat, Nov 9, 2024 at 6:01 PM Ben Koenig [email protected] wrote: > > > Had to go look it up, but if anyone is curious why I suggested being extra > > methodical with troubleshooting... the HP Z420 has known USB3.0 quirks. > > check out the following functions (and comments) from the linux xhci source > > code (6.6.x): > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/usb/host/xhci.c?h=v6.6.60#n365 > > > > compliance_mode_recovery_timer_init() > > xhci_compliance_mode_recovery_timer_quirk_check() > > > > There are known problems with the redriver for this machine that causes the > > ports to go dead. There's not much you can see via software once that > > happens. > > > > Also affects Z620, x820 and Z1 workstations. Assume nothing. Verify simple > > devices first and add complexity until it breaks. > > > > -Ben > > > > On Saturday, November 9th, 2024 at 5:32 PM, Ben Koenig > > [email protected] wrote: > > > > > Mot ready to conclude anything yet, just a couple more things to try. > > > > > > Next step is to do a cold boot of the workstation. Turn it off, and > > > UNPLUG the power cable. Make sure the motherboard drains either by > > > waiting or pressing the power button while unplugged from the wall. > > > > > > Then boot it up with only your mouse and keyboard connected (however you > > > usually do that) since those appear to be working just fine. > > > > > > Once everything is up, running, and happy open a terminal, start dmesg -w > > > as before and plug in your logitech headphones to each USB port on the > > > back, one by one. Check to make sure each one responds in dmesg. When you > > > unplug you will see a cooresponding disconnect message for that USB port. > > > > > > This part is important, use the LOGITECH HEADSET. You confirmed that this > > > works via the older USB2 ports so we are going to call it youre "golden > > > device" It's also much simply since it won't try to create any block > > > devices. Don't try to plug in your sandisk USB stick until you've checked > > > to make sure each port sees your golden device. > > > > > > -Ben > > > > > > On Saturday, November 9th, 2024 at 5:20 PM, American Citizen > > > [email protected] wrote: > > > > > > > Ben: > > > > > > > > I carefully followed your directions. > > > > > > > > When I plugged in my USB flash drive into a USB cable, nothing happened, > > > > nothing! > > > > > > > > I pulled out my Logitech headphones connected with a USB 2.0 port and > > > > dmesg -w caught that > > > > > > > > But I am plugging my USB stick into the two USB 3.0 sockets and NOTHING > > > > comes up > > > > > > > > The Z420 workstation has front panel USB socket.. they are from top to > > > > bottom: USB2, USB3, USB3 > > > > > > > > When I pick the top USB2 slot, the following dmesg messages come up > > > > > > > > [3225340.916530] usb 1-1.3: new high-speed USB device number 8 using > > > > ehci-pci > > > > [3225341.037689] usb 1-1.3: New USB device found, idVendor=0781, > > > > idProduct=5597, bcdDevice= 1.00 > > > > [3225341.037701] usb 1-1.3: New USB device strings: Mfr=1, Product=2, > > > > SerialNumber=3 > > > > [3225341.037705] usb 1-1.3: Product: SanDisk 3.2Gen1 > > > > [3225341.037708] usb 1-1.3: Manufacturer: USB > > > > [3225341.037711] usb 1-1.3: SerialNumber: > > > > 09012829b8b34ac0b32423247f16c72e303c7bc976805b653909ab36c22e3dcacf880000000000000000000074408ef6ff082d209755810711ae56dd > > > > [3225341.038089] usb-storage 1-1.3:1.0: USB Mass Storage device detected > > > > [3225341.092530] scsi host7: usb-storage 1-1.3:1.0 > > > > [3225342.121945] scsi 7:0:0:0: Direct-Access USB SanDisk > > > > 3.2Gen1 1.00 PQ: 0 ANSI: 6 > > > > [3225342.123655] sd 7:0:0:0: Attached scsi generic sg4 type 0 > > > > [3225342.124195] sd 7:0:0:0: [sdd] 488374272 512-byte logical blocks: > > > > (250 GB/233 GiB) > > > > [3225342.125193] sd 7:0:0:0: [sdd] Write Protect is off > > > > [3225342.125199] sd 7:0:0:0: [sdd] Mode Sense: 43 00 00 00 > > > > [3225342.126191] sd 7:0:0:0: [sdd] Write cache: disabled, read cache: > > > > enabled, doesn't support DPO or FUA > > > > [3225342.247842] sdd: sdd1 > > > > [3225342.248001] sd 7:0:0:0: [sdd] Attached SCSI removable disk > > > > > > > > All this is correct and I have access to the flash drive. > > > > > > > > Is the USB 3.0 circuitry in my Hewlett-Packard Z420 workstation broken? > > > > > > > > Randall > > > > > > > > On 11/9/24 09:50, Ben Koenig wrote: > > > > > > > > > On Friday, November 8th, 2024 at 8:15 PM, American Citizen > > > > > [email protected] wrote: > > > > > > > > > > > I have a Hewlett Packard Z420 workstation. About a week ago, the USB > > > > > > ports stopped working. Tonight I identified that it is the USB 3.0 > > > > > > ports > > > > > > that are not working, the USB 2.0 is still working just fine. > > > > > > > > > > > > Has anyone had experience troubleshooting USB 3.0 ports under linux? > > > > > > > > > > > > - Randall > > > > > > > > > > Based on your description of the problem the OS is irrelevant. Most > > > > > of the troubleshooting at this stage is pure hardware. > > > > > > > > > > If you want, you can use the following commands to see if the USB3 > > > > > host controller is detected by Linux and if any devices are detected. > > > > > To see a brief list of all USB devices, including host controllers: > > > > > $ lsusb > > > > > > > > > > To see what happens when a device is inserted, unplug all devices > > > > > from your USB3 slots and then run the following command (as root): > > > > > $ dmesg -w > > > > > > > > > > The -w argument tells dmesg to print the log and any new messages as > > > > > they occur. Once you have that running you can plug in a USB device > > > > > and it should immediately start printing messages related to the > > > > > device you inserted. > > > > > > > > > > You can also automate this to only give you the difference, here's a > > > > > rough example. > > > > > dmesg > dmesg-before.log > > > > > # insert the device > > > > > dmesg > dmesg-after.log > > > > > diff dmesg-before.log dmesg-after.log > > > > > > > > > > Either way, when running into USB problems I always step away from > > > > > the OS. It's much better to start with a "golden device" such as a > > > > > mouse or keyboard that you know works and diagnose with that. > > > > > > > > > > -Ben
