Message-ID: <c34c6dc2-5ab2-1a81-3ba4-b3bc2c016945@linux.intel.com>
Date: Tue, 1 Apr 2025 20:38:48 +0300 (EEST)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: Guenter Roeck <linux@...ck-us.net>
cc: Bjorn Helgaas <bhelgaas@...gle.com>, linux-pci@...r.kernel.org, 
    Michał Winiarski <michal.winiarski@...el.com>, 
    Igor Mammedov <imammedo@...hat.com>, LKML <linux-kernel@...r.kernel.org>, 
    Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH 24/25] PCI: Perform reset_resource() and build fail list
 in sync

On Tue, 1 Apr 2025, Guenter Roeck wrote:
> On 4/1/25 05:07, Ilpo Järvinen wrote:
> > On Tue, 1 Apr 2025, Ilpo Järvinen wrote:
> > 
> > > On Mon, 31 Mar 2025, Guenter Roeck wrote:
> > > > On Mon, Dec 16, 2024 at 07:56:31PM +0200, Ilpo Järvinen wrote:
> > > > > Resetting resource is problematic as it prevent attempting to allocate
> > > > > the resource later, unless something in between restores the resource.
> > > > > Similarly, if fail_head does not contain all resources that were
> > > > > reset,
> > > > > those resource cannot be restored later.
> > > > > 
> > > > > The entire reset/restore cycle adds complexity and leaving resources
> > > > > into reseted state causes issues to other code such as for checks done
> > > > > in pci_enable_resources(). Take a small step towards not resetting
> > > > > resources by delaying reset until the end of resource assignment and
> > > > > build failure list (fail_head) in sync with the reset to avoid leaving
> > > > > behind resources that cannot be restored (for the case where the
> > > > > caller
> > > > > provides fail_head in the first place to allow restore somewhere in
> > > > > the
> > > > > callchain, as is not all callers pass non-NULL fail_head).
> > > > > 
> > > > > The Expansion ROM check is temporarily left in place while building
> > > > > the
> > > > > failure list until the upcoming change which reworks optional resource
> > > > > handling.
> > > > > 
> > > > > Ideally, whole resource reset could be removed but doing that in a big
> > > > > step would make the impact non-tractable due to complexity of all
> > > > > related code.
> > > > > 
> > > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
> > > > 
> > > > With this patch in the mainline kernel, all mips:boston qemu emulations
> > > > fail when running a 64-bit little endian configuration
> > > > (64r6el_defconfig).
> > > > 
> > > > The problem is that the PCI based IDE/ATA controller is not initialized.
> > > > There are a number of pci error messages.
> > > > 
> > > > pci_bus 0002:01: extended config space not accessible
> > > > pci 0002:01:00.0: [8086:2922] type 00 class 0x010601 conventional PCI
> > > > endpoint
> > > > pci 0002:01:00.0: BAR 4 [io  0x0000-0x001f]
> > > > pci 0002:01:00.0: BAR 5 [mem 0x00000000-0x00000fff]
> > > > pci 0002:00:00.0: PCI bridge to [bus 01-ff]
> > > > pci_bus 0002:01: busn_res: [bus 01-ff] end is updated to 01
> > > > pci 0002:00:00.0: bridge window [mem 0x16000000-0x160fffff]: assigned
> > > > pci 0002:00:00.0: bridge window [mem size 0x00100000 64bit pref]: can't
> > > > assign; no space
> > > > pci 0002:00:00.0: bridge window [mem size 0x00100000 64bit pref]: failed
> > > > to assign
> > > > pci 0002:00:00.0: bridge window [io  size 0x1000]: can't assign; no
> > > > space
> > > > pci 0002:00:00.0: bridge window [io  size 0x1000]: failed to assign
> > > > pci 0002:00:00.0: bridge window [mem size 0x00100000]: can't assign;
> > > > bogus alignment
> > > > pci 0002:00:00.0: bridge window [mem 0x16000000-0x160fffff 64bit pref]:
> > > > assigned
> > > > pci 0002:00:00.0: bridge window [io  size 0x1000]: can't assign; no
> > > > space
> > > > pci 0002:00:00.0: bridge window [io  size 0x1000]: failed to assign
> > > > pci 0002:01:00.0: BAR 5 [mem size 0x00001000]: can't assign; no space
> > > > pci 0002:01:00.0: BAR 5 [mem size 0x00001000]: failed to assign
> > > > pci 0002:01:00.0: BAR 4 [io  size 0x0020]: can't assign; no space
> > > > pci 0002:01:00.0: BAR 4 [io  size 0x0020]: failed to assign
> > > > pci 0002:01:00.0: BAR 5 [mem size 0x00001000]: can't assign; no space
> > > > pci 0002:01:00.0: BAR 5 [mem size 0x00001000]: failed to assign
> > > > pci 0002:01:00.0: BAR 4 [io  size 0x0020]: can't assign; no space
> > > > pci 0002:01:00.0: BAR 4 [io  size 0x0020]: failed to assign
> > > > pci 0002:00:00.0: PCI bridge to [bus 01]
> > > > pci 0002:00:00.0:   bridge window [mem 0x16000000-0x160fffff 64bit pref]
> > > > pci_bus 0002:00: Some PCI device resources are unassigned, try booting
> > > > with pci=realloc
> > > > pci_bus 0002:00: resource 4 [mem 0x16000000-0x160fffff]
> > > > pci_bus 0002:01: resource 2 [mem 0x16000000-0x160fffff 64bit pref]
> > > > ...
> > > > pci 0002:00:00.0: enabling device (0000 -> 0002)
> > > > ahci 0002:01:00.0: probe with driver ahci failed with error -12
> > > > 
> > > > Bisect points to this patch. Reverting it together with "PCI: Rework
> > > > optional resource handling" fixes the problem. For comparison, after
> > > > reverting the offending patches, the log messages are as follows.
> > > > 
> > > > pci_bus 0002:00: root bus resource [bus 00-ff]
> > > > pci_bus 0002:00: root bus resource [mem 0x16000000-0x160fffff]
> > > > pci 0002:00:00.0: [10ee:7021] type 01 class 0x060400 PCIe Root Complex
> > > > Integrated Endpoint
> > > > pci 0002:00:00.0: PCI bridge to [bus 00]
> > > > pci 0002:00:00.0:   bridge window [io  0x0000-0x0fff]
> > > > pci 0002:00:00.0:   bridge window [mem 0x00000000-0x000fffff]
> > > > pci 0002:00:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
> > > > pci 0002:00:00.0: enabling Extended Tags
> > > > pci 0002:00:00.0: bridge configuration invalid ([bus 00-00]),
> > > > reconfiguring
> > > > pci_bus 0002:01: extended config space not accessible
> > > > pci 0002:01:00.0: [8086:2922] type 00 class 0x010601 conventional PCI
> > > > endpoint
> > > > pci 0002:01:00.0: BAR 4 [io  0x0000-0x001f]
> > > > pci 0002:01:00.0: BAR 5 [mem 0x00000000-0x00000fff]
> > > > pci 0002:00:00.0: PCI bridge to [bus 01-ff]
> > > > pci_bus 0002:01: busn_res: [bus 01-ff] end is updated to 01
> > > > pci 0002:00:00.0: bridge window [mem 0x16000000-0x160fffff]: assigned
> > > > pci 0002:00:00.0: bridge window [mem size 0x00100000 64bit pref]: can't
> > > > assign; no space
> > > > pci 0002:00:00.0: bridge window [mem size 0x00100000 64bit pref]: failed
> > > > to assign
> > > > pci 0002:00:00.0: bridge window [io  size 0x1000]: can't assign; no
> > > > space
> > > > pci 0002:00:00.0: bridge window [io  size 0x1000]: failed to assign
> > > > pci 0002:01:00.0: BAR 5 [mem 0x16000000-0x16000fff]: assigned
> > > > pci 0002:01:00.0: BAR 4 [io  size 0x0020]: can't assign; no space
> > > > pci 0002:01:00.0: BAR 4 [io  size 0x0020]: failed to assign
> > > > pci 0002:00:00.0: PCI bridge to [bus 01]
> > > > pci 0002:00:00.0:   bridge window [mem 0x16000000-0x160fffff]
> > > > pci_bus 0002:00: Some PCI device resources are unassigned, try booting
> > > > with pci=realloc
> > > > pci_bus 0002:00: resource 4 [mem 0x16000000-0x160fffff]
> > > > pci_bus 0002:01: resource 1 [mem 0x16000000-0x160fffff]
> > > > ...
> > > > pci 0002:00:00.0: enabling device (0000 -> 0002)
> > > > ahci 0002:01:00.0: enabling device (0000 -> 0002)
> > > > ahci 0002:01:00.0: AHCI vers 0001.0000, 32 command slots, 1.5 Gbps, SATA
> > > > mode
> > > > ahci 0002:01:00.0: 6/6 ports implemented (port mask 0x3f)
> > > > ahci 0002:01:00.0: flags: 64bit ncq only
> > > 
> > > Hi,
> > > 
> > > Thanks for reporting. Please add this to the command line to get the
> > > resource releasing between the steps to show:
> > > 
> > > dyndbg="file drivers/pci/setup-bus.c +p"
> > > 
> > > Also, the log snippet just shows it fails but it is impossible to know
> > > from it why the resource assigments do not fit so could you please provide
> > > a complete dmesg logs. Also providing the contents of /proc/iomem from the
> > > working case would save me quite a bit of decoding the iomem layout from
> > > the dmesgs.
> > 
> > Hi again,
> > 
> > If you could kindly include this patch into the test with pci_dbg()
> > enabled so the resource reset/restore is better tracked.
> > 
> 
> Same link as before (http://server.roeck-us.net/qemu/mipsel64/).
> The log with the patch applied is in bad-extra.log.

That log wasn't taken from a bad case but it doesn't matter anymore as I 
could test this with qemu myself, thanks for providing enough to make it 
easy to reproduce & test it locally :-).

The problem is caused by assign+release cycle being destructive on start 
aligned resources because successful assigment overwrites the start field. 
I'll send a patch to fix the problem once I've given it a bit more thought
as this resource fitting code is somewhat complex.

-- 
 i.

Powered by blists - more mailing lists