[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <wxb4hmju5jknxr2bclxlu5gujgmb3vvqwub7jrt4wofllqp7li@pdvthto4jf47>
Date: Fri, 15 Nov 2024 11:35:46 +0000
From: Shinichiro Kawasaki <shinichiro.kawasaki@....com>
To: Hans de Goede <hdegoede@...hat.com>
CC: "Daniel Walker (danielwa)" <danielwa@...co.com>, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com>, Ilpo J�rvinen
<ilpo.jarvinen@...ux.intel.com>, Klara Modin <klarasmodin@...il.com>, Greg
Kroah-Hartman <gregkh@...uxfoundation.org>, Danil Rybakov
<danilrybakov249@...il.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "xe-linux-external(mailer list)"
<xe-linux-external@...co.com>
Subject: Re: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device
probe
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.
View attachment "p2sb_debug.patch" of type "text/plain" (1769 bytes)
Powered by blists - more mailing lists