Solved Kernel fix for xhci timeout on install

loveydovey

loveydovey

Same machine: on Linux USB works, on FreeBSD 14.5 it doesn't. (Lenovo B50-80)

So I couldn't even install FreeBSD via USB because of this USB error. The error:

Code: 
xhci0: <Intel Panther Point USB 3.0 controller> mem 0xb2500000-0xb250ffff irq 7 at device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
xhci0: Controller reset timeout.
xhci0: XHCI halt/start/probe failed err=18
xhci0: Controller reset timeout.
device_attach: xhci0 attach returned 6

Turning off xhci did not help, USB was not working.

Linux works because its xHCI driver has some quirks that allow for the controller to come out of a reset. I guess it has more workarounds for older Intel controllers and is more aggressive about taking ownership from BIOS.

I tried these fixes to no avail:

Code: 
hw.pci.enable_msi=0
hw.pci.enable_msix=0
hw.usb.xhci.route=-1

So I started getting aggressive with workarounds and edited kernel code to allow for a more patient reset.

I actually did two modifications in xhci controller - increased the reset waiting loop by about 50x and changed it to ignore "controller reset timeout" error returned by the controller.

This actually made worked - on boot the controller was stuck on xhci initialization for a few seconds and then initialized it, and USB started to work properly. On shutdown it also lingers for a few more seconds longer before powering off.

This is System Hardware topic, but I feel this is more important for Installation since it precludes USB installs.

Question - can this be patched in kernel, or does FreeBSD make it so strict on purpose? Can this kernel change be made like an option so that the older Intel controllers work? What should I do?

Shoutout to Grok for helping me get USB to work on FreeBSD on Lenovo B50-80.
 
I just tested just increasing the loop timing, it doesn't work...it never gets past the controller reset error. I guess the controller reset bit never flips.

I'm going to now try to just comment out the controller reset error and see what happens.
 
It's literally that. Ignoring the controller reset error fixes everything. Everything loads fast and proper.

This really needs to be exposed as an option so people can disable it if need be.

I wonder if it doesn't reset properly because FreeBSD is not initiating it properly, but that's up to the big_brains@developersoffreebsd.org to figure out.
 
Please open a bug report with your diff.

It certainly sounds like something that could at least be an option, if not automatic by chipset.
 
You must log in or register to reply here.
Back
Top