Re: [6.12.y regression] Regression with 58130e7ce6cb ("PCI/ERR: Ensure error recoverability at all times"): echo vfio-pci >driver_override does not work for DVB Adapter

[Lukas Wunner <lukas@wunner.de>]

On Mon, Mar 30, 2026 at 08:14:53AM +0200, Bernd Schumacher wrote:
> [    0.318903] pci 0000:07:00.0: [dd01:0003] type 00 class 0x048000 PCIe Endpoint
> [    0.318939] pci 0000:07:00.0: BAR 0 [mem 0xfffffffffc500000-0xfffffffffc50ffff 64bit]

BIOS initially sets the BAR address to an incorrect value (the top 32 bits
should be all zeroes instead of all ones)...

> [    0.339685] pci 0000:07:00.0: BAR 0 [mem 0xfffffffffc500000-0xfffffffffc50ffff 64bit]: can't claim; no compatible bridge window
[...]
> [    0.311065] pci 0000:02:03.0: [1022:57a3] type 01 class 0x060400 PCIe Switch Downstream Port
> [    0.311107] pci 0000:02:03.0: PCI bridge to [bus 07]
> [    0.311118] pci 0000:02:03.0:   bridge window [mem 0xfc500000-0xfc5fffff]

... this doesn't fit into the window of the bridge above the DVB card,
which has the top 32 bits set to all zeroes...

> [    0.357346] pci 0000:07:00.0: BAR 0 [mem 0xfc500000-0xfc50ffff 64bit]: assigned

... the kernel fixes the incorrect BAR, but it seems there's an ordering
issue such that pci_save_state() is called beforehand.  It's weird that
this doen't occur with newer kernels and it would be good to understand why.
I'm not seeing the ordering issue despite staring at the code for a while.

Below is a small debug patch.  Could you apply that on top of v6.12.73
(or newer) and provide me with the resulting full dmesg output?

The patch emits a stacktrace when correcting the BAR value as well as
when saving and restoring config space of the DVB card.  This should
give a clue where the ordering issue originates from.

Please note that the log_buf_len=16M parameter needs to be put outside
the double quotes of the dyndbg parameter, i.e.:

GRUB_CMDLINE_LINUX='log_buf_len=16M dyndbg="file drivers/pci/* +p"'

The dmesg output provided most recently no longer contained the dyndbg
output, probably because log_buf_len was intermixed with the double quoted
string.

Thanks for your continued patience in helping root-cause this issue!

Lukas