On Nov 13, 2024 / 19:34, Hans de Goede wrote:
> Hi,
> 
> On 13-Nov-24 6:41 PM, Daniel Walker (danielwa) wrote:
> > On Wed, Nov 13, 2024 at 06:04:44PM +0100, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 13-Nov-24 5:33 PM, Hans de Goede wrote:
> >>> Hi,
> >>>
> >>> On 13-Nov-24 5:24 PM, Hans de Goede wrote:
[...]
> >>> It probably has something to do with these 2 messages:
> >>>
> >>> pci 0000:00:1f.1: BAR 0 [mem 0xfd000000-0xfdffffff 64bit]: can't claim; no compatible bridge window
> >>> pci 0000:00:1f.1: BAR 0 [mem 0x280000000-0x280ffffff 64bit]: assigned
> >>>
> >>> I'm guessing that this re-assignment is messing up
> >>> the p2sb BAR caching, after which things go wrong.
> >>
> >> Hmm, but that should be fixed by 2c6370e66076 ("platform/x86: p2sb: Don't init until unassigned resources have been assigned")
> >>
> >> and you are seeing this with 6.12, which has that.
> >>
> >> Can you try adding a pr_info() to the top of p2sb_cache_resources()
> >> with 6.12 and then collec a new dmesg ?
> >>
> >> If that pr_info() is done after the:
> >>
> >> pci 0000:00:1f.1: BAR 0 [mem 0x280000000-0x280ffffff 64bit]: assigned
> >>
> >> message then that does not explain things.
> >>
> > 
> > I haven't testing adding a pr_info() but the messages seem to happen in the same
> > order in both working and non-working cases.
> > 
> > Does that matter?
> 
> The working case does not do the bar caching, we want to know if the
> bar caching in the non working case happens before or after the assignment:
> 
> pci 0000:00:1f.1: BAR 0 [mem 0x280000000-0x280ffffff 64bit]: assigned
> 
> It should happen after the assignment.

Hello Daniel,

It's my sorrow that the change cause this trouble. I have created a debug patch
for the kernel and attached to this e-mail. It adds some pr_info() to answer
the question from Hans. It will also show us a bit more things. Could you try it
on your system? It should apply to v6.12-rcX kernels without conflicts.