Re: USB controller broken by zero cacheline size in PCIe to PCI bridge

[Michal Pecio <michal.pecio@gmail.com>]

On Mon, 16 Mar 2026 15:06:49 -0500, Bjorn Helgaas wrote:
> Is there an actual functional problem like data corruption, or is it
> purely a performance issue?

It's functional failure - some USB devices don't even enumerate,
storage quickly gets stuck and starts being reset by USB forever,
video camera loses enough data packets that no image shows, etc.

Curiously, Windows 10 64 has similar problems and same solution -
with some hassle I got the pciutils port to work. Windows doesn't
change cache line size on any device in this machine at all.

In my case it seems that CLS only needs to be set on the bridge. 
According to bridge datasheet, this value is used to decide when to
use Read, Memory Read Line, Memory Read Multiple and MWI commands.
But per PCI spec, behavior of some commands depends on cache line,
so maybe it should ideally be consistent across the bus.

> The Cache Line Size depends on the CPU, so maybe the good and bad
> machines have different CPUs?  Can you collect /proc/cpuinfo for each?
> 
> I don't think the Cache Line Size depends on the actual PCI devices,
> so the PCI core really should configure it for every bridge and device
> during enumeration, but I don't think it does.

Good and bad systems are both x86-64 with 64B cache line, and as you
said, it semes that Linux (and Windows) just use what the BIOS left.

I patched pci_setup_device() to print it. On bad system all devices
are zero except one out of two AHCI controllers. On good system most
are 64, though some are zero. My card gets 64. Changing it to zero
breaks the good system too.

The bad machine is a proprietary HP business PC with only PCIe slots.

> In your case, ehci_pci_reinit() might set it for the uPD72010x EHCI
> controller, and it looks like Cache Line Size is set to 64 bytes in
> both the good and bad systems.

It's odd that the kernel sets it here but trusts boot FW otherwise.
I wonder if there are any official rules for this in x86-land.

> The Cache Line Size configuration (or lack of it) is kind of a
> historical mess, and it only applies to conventional PCI, not PCIe,
> so I don't really know how to untangle it.

Not sure either. Setting proper CLS (if known) at boot would fix it.
Question is if it could break something else.

I also don't know if it's a common problem. Looks like it takes a
particular BIOS behavior, maybe a particular bridge, and a particular
device, because OHCI functions of the same NEC chip appear to work,
only EHCI is obviously broken.

Regards,
Michal