[+to Jesse, Tony for Intel advice;
beginning of thread:
https://lore.kernel.org/all/20201230185317.30915-1-michael@xxxxxxxx/]
On Mon, Dec 20, 2021 at 06:43:03PM +0100, Michael Walle wrote:
...
ping #4
In a few days this is a year old. Please have a look at it and
either add my quirk patch or apply your patch. This is still
breaking i210 on my board.
TBH, this is really frustrating.
You are right to be frustrated. I'm very sorry that I have dropped
the ball on this. Thanks for reminding me *again*.
I think we agree that this looks like an I210 defect. I210 should
ignore the ROM BAR contents unless PCI_ROM_ADDRESS_ENABLE is set. It
would be great if an Intel person could confirm/deny this and supply
an erratum reference and verify the affected device IDs.
It seems that when the BARs are programmed like this:
BAR 0: 0x40000000 (32-bit, non-prefetchable) [size=1M]
BAR 3: 0x40200000 (32-bit, non-prefetchable) [size=16K]
ROM: 0x40200000 (disabled) [size=1M]
networking doesn't work at all and the transmit queue times out.
Linux assigns non-overlapping address space to the ROM BAR, but
pci_std_update_resource() currently doesn't update the BAR itself
unless it is enabled.
My proposal [1] worked around the defect by always updating the BAR,
but there's no clue that this covers up the I210 issue, so it remains
as sort of a land mine. A future change could re-expose the problem,
so I don't think this was a good approach.
Your original patch [2] makes it clear that it's an issue with I210,
but there's an implicit connection between the normal BAR update path
(which skips the actual BAR write) and the quirk that does the BAR
write:
<enumeration resource assignment>
...
pci_assign_resource
pci_update_resource
pci_std_update_resource
if (ROM && ROM-disabled)
return
pci_write_config_dword # ROM BAR update (skipped)
pci_fixup_write_rom_bar # final fixup
pci_write_config_dword # ROM BAR update
In the boot-time resource assignment path, this works fine, but if
pci_assign_resource() is called from pci_map_rom(), the fixup will not
happen, so we could still have problem.
If we tweaked pci_std_update_resource() to take account of this
defect, I think we could cover that path, too.
Can you try the patch below?