The onboard USB3 ports are just not being detected. I built a new stable kernel, 6.11.7, checked BIOS settings, the USB3 ports are enabled. The only quirks lines in dmesg output is for the PCIe card I added.
I don't actually need the USB3 ports, because of the card, so ... I give up. Something is haywire and there isn't enough information to figure out what. -- Russell Senior [email protected] On Sun, Nov 10, 2024 at 4:40 PM Ben Koenig <[email protected]> wrote: > > 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
