Re: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)

[Matt Turner]

On Mon, Apr 23, 2018 at 10:34 AM, Ivan Kokshaysky
 wrote:
> On Sun, Apr 22, 2018 at 01:07:38PM -0700, Matt Turner wrote:
>> On Wed, Apr 18, 2018 at 1:48 PM, Ivan Kokshaysky
>>  wrote:
>> > On Tue, Apr 17, 2018 at 02:43:44PM -0500, Bjorn Helgaas wrote:
>> >> On Mon, Apr 16, 2018 at 09:43:42PM -0700, Matt Turner wrote:
>> >> > On Mon, Apr 16, 2018 at 2:50 PM, Bjorn Helgaas  
>> >> > wrote:
>> >> > > Hi Matt,
>> >> > >
>> >> > > First of all, sorry about breaking Nautilus, and thanks very much for
>> >> > > tracking it down to this commit.
>> >> >
>> >> > It's a particularly weird case, as far as I've been able to discern :)
>> >> >
>> >> > > On Mon, Apr 16, 2018 at 07:33:57AM -0700, Matt Turner wrote:
>> >> > >> Commit f75b99d5a77d63f20e07bd276d5a427808ac8ef6 (PCI: Enforce bus
>> >> > >> address limits in resource allocation) broke Alpha systems using
>> >> > >> CONFIG_ALPHA_NAUTILUS. Alpha is 64-bit, but Nautilus systems use a
>> >> > >> 32-bit AMD 751/761 chipset. arch/alpha/kernel/sys_nautilus.c maps PCI
>> >> > >> into the upper addresses just below 4GB.
>> >> > >>
>> >> > >> I can get a working kernel by ifdef'ing out the code in
>> >> > >> drivers/pci/bus.c:pci_bus_alloc_resource. We can't tie
>> >> > >> PCI_BUS_ADDR_T_64BIT to ALPHA_NAUTILUS without breaking generic
>> >> > >> kernels.
>> >> > >>
>> >> > >> How can we get Nautilus working again?
>> >> > >
>> >> > > Can you collect a complete dmesg log, ideally both before and after
>> >> > > f75b99d5a77d?  I assume the problem is that after f75b99d5a77d? we
>> >> > > erroneously assign space for something above 4GB.  But if we know the
>> >> > > correct host bridge apertures, we shouldn't assign space outside them,
>> >> > > regardless of the PCI bus address size.
>> >> >
>> >> > I made a mistake in my initial report. Commit f75b99d5a77d is actually
>> >> > the last *working* commit. My apologies. The next commit is
>> >> > d56dbf5bab8c (PCI: Allocate 64-bit BARs above 4G when possible) and it
>> >> > breaks Nautilus I've confirmed.
>> >> >
>> >> > Please find attached dmesgs from those two commits, from the commit
>> >> > immediately before them, and another from 4.17-rc1 with my hack of #if
>> >> > 0'ing out the pci_bus_alloc_from_region(..., _high) code.
>> >> >
>> >> > Thanks for having a look!
>> >>
>> >> We're telling the PCI core that the host bridge MMIO aperture is the
>> >> entire 64-bit address space, so when we assign BARs, some of them end
>> >> up above 4GB:
>> >>
>> >>   pci_bus :00: root bus resource [mem 0x-0x]
>> >>   pci :00:09.0: BAR 0: assigned [mem 0x1-0x1 64bit]
>> >>
>> >> But it sounds like the MMIO aperture really ends at 0x, so
>> >> that's not going to work.
>> >
>> > Correct... This would do as a quick fix, I think:
>> >
>> > diff --git a/arch/alpha/kernel/sys_nautilus.c 
>> > b/arch/alpha/kernel/sys_nautilus.c
>> > index ff4f54b..477ba65 100644
>> > --- a/arch/alpha/kernel/sys_nautilus.c
>> > +++ b/arch/alpha/kernel/sys_nautilus.c
>> > @@ -193,6 +193,8 @@ static struct resource irongate_io = {
>> >  };
>> >  static struct resource irongate_mem = {
>> > .name   = "Irongate PCI MEM",
>> > +   .start  = 0,
>> > +   .end= 0x,
>> > .flags  = IORESOURCE_MEM,
>> >  };
>> >  static struct resource busn_resource = {
>> > @@ -218,7 +220,7 @@ nautilus_init_pci(void)
>> > return;
>> >
>> > pci_add_resource(>windows, _resource);
>> > -   pci_add_resource(>windows, _resource);
>> > +   pci_add_resource(>windows, _mem);
>> > pci_add_resource(>windows, _resource);
>> > bridge->dev.parent = NULL;
>> > bridge->sysdata = hose;
>>
>> Thanks. But with that I get
>>
>> PCI host bridge to bus :00
>> pci_bus :00: root bus resource [io  0x-0x]
>> pci_bus :00: root bus resource [mem 0x-0x]
>> pci_bus :00: root bus resource [bus 00-ff]
>> pci :00:10.0: [Firmware Bug]: reg 0x10: invalid BAR (can't size)
>> pci :00:10.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
>> pci :00:10.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
>> pci :00:10.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
>> pci :00:10.0: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
>> pci :00:10.0: legacy IDE quirk: reg 0x14: [io  0x03f6]
>> pci :00:10.0: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
>> pci :00:10.0: legacy IDE quirk: reg 0x1c: [io  0x0376]
>> pci :00:11.0: quirk: [io  0x4000-0x403f] claimed by ali7101 ACPI
>> pci :00:11.0: quirk: [io  0x5000-0x501f] claimed by ali7101 SMB
>> pci :00:01.0: BAR 9: assigned [mem 0xc000-0xc2ff pref]
>> pci :00:01.0: BAR 8: assigned [mem 0xc300-0xc3bf]
>> pci :00:0b.0: BAR 6: assigned [mem 0xc3c0-0xc3c3 pref]
>> pci :00:08.0: BAR 6: assigned [mem 0xc3c4-0xc3c5 pref]
>> 

Re: [PATCH v3 1/3] alpha: Use OPTIMIZE_INLINING instead of asm/compiler.h

[Matt Turner]

On Tue, Apr 17, 2018 at 3:11 AM, James Hogan  wrote:
> Use CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING and CONFIG_OPTIMIZE_INLINING
> instead of undefining the inline macros in the alpha specific
> asm/compiler.h. This is to allow asm/compiler.h to become a general
> header that can be used for overriding linux/compiler*.h.
>
> A build of alpha's defconfig on GCC 7.3 before and after this series
> (i.e. this commit and "compiler.h: Allow arch-specific overrides" which
> includes asm/compiler.h from linux/compiler_types.h) results in the
> following size differences, which appear harmless to me:
>
> $ ./scripts/bloat-o-meter vmlinux.1 vmlinux.2
> add/remove: 1/1 grow/shrink: 3/0 up/down: 264/-348 (-84)
> Function old new   delta
> cap_bprm_set_creds  14961664+168
> cap_issubset   -  68 +68
> flex_array_put   328 344 +16
> cap_capset   488 500 +12
> nonroot_raised_pE.constprop  348   --348
> Total: Before=5823709, After=5823625, chg -0.00%
>
> Suggested-by: Arnd Bergmann 
> Signed-off-by: James Hogan 
> Cc: Richard Henderson 
> Cc: Ivan Kokshaysky 
> Cc: Matt Turner 
> Cc: linux-alpha@vger.kernel.org

Looks fine to me.

Acked-by: Matt Turner 

Should I take it through the alpha tree?
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html