From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: "René Rebe" <rene@exactco.de>
Cc: glaubitz@physik.fu-berlin.de, linux-pci@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
bhelgaas@google.com, riccardo.mottola@libero.it
Subject: Re: PCI bridge window issue
Date: Tue, 2 Dec 2025 21:35:47 +0200 (EET) [thread overview]
Message-ID: <051199db-1c34-3e70-c028-73f850ff30f0@linux.intel.com> (raw)
In-Reply-To: <20251202.192907.1946164892504460809.rene@exactco.de>
[-- Attachment #1: Type: text/plain, Size: 2370 bytes --]
On Tue, 2 Dec 2025, René Rebe wrote:
> Hi Ilpo,
>
> On Tue, 2 Dec 2025 20:20:09 +0200 (EET), Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> wrote:
>
> > On Tue, 2 Dec 2025, René Rebe wrote:
> >
> > > s390x. Maybe users of those want to allow list after testing? Now that
> > > I think about it I was wondering why ALSA RAD1 audio is not longer
> > > working in my Sgi Octane with the PCI window not being enabled. Would
> > > not suprise me it was some change like this, too. Should bisect next
> >
> > Hi René,
> >
> > Could you please send me a dmesg and contents of the /proc/iomem (taken
> > with root right so it shows the real addresses) so I can look at this PCI
> > bridge window issue. If you know a working kernel, having logs from
> > working and broken case would be very helpful to easily locate the
> > differences.
>
> Thank you so much for offering help with that different
> issue. Sgi/Octane IP30 only went upstream some years ago. I only have
> the likewise not upstream snd-rad1 working with much older out of tree
> kernels. Thanks you for the hints, I'll try to find some time to to
> further debug this soon to bring the snd-rad1 ALSA driver upstream,
> too.
Okay, if it's an old issue, it's likely not because of the recent PCI core
changes.
If there are "can't assign" or "no compatible bridge window" lines for
PCI resources in the log, those happen before some endpoint driver even
comes into picture so it could be PCI core issue so in that sense it might
not matter if the endpoint driver is in-tree or out-of-tree as long as the
kernel you're testing with is otherwise "new enough" to contain the recent
changes and fixes to PCI subsystem.
--
i.
> > At this point, no need to bisect as I might be able to figure it out even
> > without pinpointing the commit. To avoid spending on issues that are
> > already know and have a fix, please check you're not running somewhat old
> > kernel as I've already fixed a few things that have gotten broken due to
> > recent made PCI bridge window fitting and assignment algorithm changes.
>
> I can not easily bisect mips64 sgi-ip30 anyway. As it was out of tree
> for 20y and the uptreamed code changed a lot during cleanup for
> merging.
>
> Good to have a contact to look into this next.
>
> Thanks!
> René
>
>
next prev parent reply other threads:[~2025-12-02 19:35 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-02 16:40 [PATCH] PCI: Fix PCI bridges not to go to D3Hot on older RISC systems René Rebe
2025-12-02 16:54 ` John Paul Adrian Glaubitz
2025-12-02 17:04 ` René Rebe
2025-12-02 18:20 ` PCI bridge window issue (Was: Re: [PATCH] PCI: Fix PCI bridges not to go to D3Hot on older RISC systems) Ilpo Järvinen
2025-12-02 18:29 ` PCI bridge window issue René Rebe
2025-12-02 19:35 ` Ilpo Järvinen [this message]
2025-12-06 1:07 ` [PATCH] PCI: Fix PCI bridges not to go to D3Hot on older RISC systems Maciej W. Rozycki
2025-12-06 8:31 ` John Paul Adrian Glaubitz
2025-12-06 10:02 ` René Rebe
[not found] ` <339B5A39-BC20-489A-9969-BF01B4E6AD63@exactco.de>
2025-12-07 14:40 ` Maciej W. Rozycki
2025-12-06 10:14 ` René Rebe
2025-12-07 14:31 ` Maciej W. Rozycki
2025-12-02 17:28 ` Bjorn Helgaas
2025-12-02 17:41 ` René Rebe
2025-12-02 21:54 ` Brian Norris
2025-12-03 4:49 ` Lukas Wunner
2025-12-03 14:27 ` Mika Westerberg
2025-12-03 14:48 ` René Rebe
2025-12-03 15:22 ` Rafael J. Wysocki
2025-12-03 15:26 ` René Rebe
2025-12-03 17:16 ` Rafael J. Wysocki
2025-12-03 5:15 ` Lukas Wunner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=051199db-1c34-3e70-c028-73f850ff30f0@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=bhelgaas@google.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rene@exactco.de \
--cc=riccardo.mottola@libero.it \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox