Re: [PATCH] PCI: Don't add failed disabled ROM BARs to fail_head

[Kameron Markham]

On Tue, 10 Nov 2026, Ilpo Järvinen wrote:

> So all resources that were assigned prior to starting were assigned
> succesfully? Which would mean there was nothing wrong with the fail_list &
> ROM resource handling.
[...]
> This might be more a quirk territory if the resources were assigned just
> fine but some device fails / crashes when given a valid address for its
> BAR(s).

Thanks for the review. You were right, so please drop this patch. I went
back and captured the end state, and it is quirk territory: the final
assignment is valid as far as anything the OS can see, but the address
it picks for the I350 is already decoded by a PCH function that the BIOS
hides.

Dell R730, BIOS 2.19.0, SR-IOV Global disabled, v6.17:

- With igb blocked (initcall_blacklist=igb_init_module) the machine
  stays up. After "No. 2 try", the bridge windows and BARs read back from
  config space match the kernel's resources exactly, e.g. 00:1c.4 (PCH
  root port [8086:8d18]) window [mem 0x92200000-0x924fffff], I350
  07:00.0 BAR 0 at 0x92200000 with memory decode enabled.

- A single 32-bit read of 07:00.0 BAR 0 + 8, without any driver, resets
  the platform. The iDRAC logs the same ME error and CPU IERR as when
  igb probes.

- With pci=realloc=off (firmware layout) and only 00:1c.4 and the I350
  moved by hand: at 0xa0000000 the I350 reads back fine (STATUS
  0x0028038f); at 0x92200000 the same read resets the platform.

- In the firmware layout nothing visible owns 0x92200000, yet reading it
  returns data instead of ~0. Exactly 0x92200000-0x92200fff decodes
  (0x92201000 onwards reads ~0), and the contents match the PCH thermal
  reporting registers as laid out in intel_pch_thermal.c: TEMP 0xa0
  (30C), TSC 0x80, TSEL 0x81, TSREL 0x01, TSMIC 0x80, CTT 0x12c (100C).

- The thermal function (00:1f.6 on C610/Wellsburg) is hidden: it isn't
  enumerated, and conf1 reads find no device at 00:1f.6 while 00:1f.0
  [8086:8d44] and 00:16.0 [8086:8d3a] answer. Its BAR keeps decoding.
  Neither the DSDT/SSDTs nor e820 mention the range.

- Its address follows the firmware layout: it is on the first 1 MB
  boundary after the last firmware-assigned MMIO below 4G, i.e.
  0x92200000 with SR-IOV Global disabled and 0x92600000 with it enabled.
  A fixed per-DMI range would therefore be wrong.

- Stock v6.17 with igb enabled plus memmap=4K$0x92200000 boots
  normally. The second pass still runs and places 00:1c.4's window at
  [mem 0x92300000-0x925fffff], and igb comes up.

Before v6.15 these bridge windows were never moved, so the overlap never
happened.

So the fix I have in mind is a quirk that reserves the hidden thermal
BAR before resources are assigned. What I don't know is how to find it
properly: with the function hidden, its BAR can't be read through normal
config space. Is there a supported way to unhide D31:F6 temporarily on
C610/X99, similar to what drivers/platform/x86/p2sb.c does for P2SB on
newer PCHs? Or would you prefer a different approach? I'm happy to write
and test whichever you think is right, and I can run any test you want
on the machine.

As this is a regression from v6.14, for tracking:

#regzbot introduced: 96336ec70264
#regzbot title: PCI: Dell R730 resets after realloc moves the I350
window over the BIOS-hidden PCH thermal BAR

The serial logs, register dumps and test scripts will go to
https://bugzilla.kernel.org/show_bug.cgi?id=222253 once bugzilla is
back.

-- 
Kameron

The investigation and these tests were done with the help of an AI
coding assistant (Claude, by Anthropic); I ran them on the hardware and
checked the results.