Opened 10 months ago

Last modified 3 weeks ago

#15000 new bug

XHCI: Can't boot off USB3 drives (but USB2 drives and/or ports work OK)

Reported by: waddlesplash Owned by: nobody
Priority: blocker Milestone: R1/beta2
Component: Drivers/USB/XHCI Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #14999, #15014, #15061, #15186, #15490, #15570
Has a Patch: no Platform: All


This seems to occur only on *some* hardware. At least my (rather common) Lynx Point controller is affected, as are the controllers on various Ryzen motherboards, and MacBooks also.

Oddly, said USB devices usually work when they are plugged in after boot, just not when they are booted from.

Change History (14)

comment:1 by waddlesplash, 10 months ago

It's possible there's some sort of rate issue here where we fire too many transactions to the device too soon after we did a power reset on all ports, perhaps? That's complete speculation though.

comment:2 by waddlesplash, 10 months ago

Blocking: 14999 added

comment:3 by waddlesplash, 10 months ago

As mentioned in the title, it is possible to boot via a USB2 flash drive on a USB3 port, or a USB3 flash drive on a USB2 port (even if said port is attached to the XHCI controller.) Something about USB3 mode is the issue here.

comment:4 by waddlesplash, 10 months ago

Debounce and wakeup times do not appear to be any different for USB3 than they were previously; at least I don't see any special handling in the Linux kernel here for this.

I do note that there are a variety of TODOs in XHCI::ConfigureEndpoint about USB2 vs. USB3 at present, most of which center around fetching the companion descriptor and then applying it to various settings. Probably that is relevant here.

comment:5 by waddlesplash, 9 months ago

Blocking: 15014 added

comment:6 by waddlesplash, 9 months ago

I just realized that, since we don't do any port resets after assuming control of the USB hardware, the USB devices will already have been configured for operation in USB3 mode, i.e. with all the parameters in ConfigureEndpoint already set from the companion descriptor. So when we set them the USB2 way, this is valid when doing an initial configuration and so the devices work after boot; but doing this for already-configured devices and never having the HCI renegotiate the link may be why things start locking up.

comment:7 by waddlesplash, 8 months ago

Blocking: 15061 added

comment:8 by waddlesplash, 8 months ago

Well, hrev53137 didn't actually help here. But I noticed while testing it (as did a user in #15061) that under USB3, the usb_disk driver does not even attempt to start on most controllers (despite the "new device connected" messages from XHCI appearing.) I wonder what's up with that? Probably it's related somehow.

comment:9 by waddlesplash, 7 months ago

hrev53194 improves this situation somewhat, though the instance of this described above ("new device connected" but no usb_disk) is not fixed; seems that's a separate issue.

comment:10 by waddlesplash, 6 months ago

Blocking: 15186 added

comment:11 by waddlesplash, 4 months ago

Milestone: UnscheduledR1/beta2
Priority: normalblocker

comment:12 by kallisti5, 2 months ago

This one should be fixed before R1 Beta2, but if nobody has the bandwidth are we going to block R1 Beta2 purely based on this issue?

comment:13 by waddlesplash, 4 weeks ago

Blocking: 15570 added

comment:14 by waddlesplash, 3 weeks ago

Blocking: 15490 added
Note: See TracTickets for help on using tickets.