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
