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: 

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: Some Alphas broken by f75b99d5a77d (PCI: Enforce bus address limits in resource allocation)

[Matt Turner]

On Wed, May 2, 2018 at 1:33 PM, Bjorn Helgaas  wrote:
> On Mon, Apr 23, 2018 at 06:34:23PM +0100, 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] 

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

[Ivan Kokshaysky]

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]
> pci :00:09.0: BAR 0: assigned [mem 0xc3c6-0xc3c6 64bit]
> pci :00:03.0: BAR 0: assigned [mem 0xc3c7-0xc3c70fff]
> pci :00:06.0: BAR 1: assigned [mem 

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

[Matt Turner]

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]
pci :00:09.0: BAR 0: assigned [mem 0xc3c6-0xc3c6 64bit]
pci :00:03.0: BAR 0: assigned [mem 0xc3c7-0xc3c70fff]
pci :00:06.0: BAR 1: assigned [mem 0xc3c71000-0xc3c71fff]
pci :00:08.0: BAR 1: assigned [mem 0xc3c72000-0xc3c72fff 64bit]
pci :00:14.0: BAR 0: assigned [mem 0xc3c73000-0xc3c73fff]
pci :00:0b.0: BAR 1: assigned [mem 0xc3c74000-0xc3c743ff]
pci :00:03.0: BAR 1: assigned [io  0x8000-0x80ff]
pci :00:06.0: 

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

[Bjorn Helgaas]

On Wed, Apr 18, 2018 at 09:48:08PM +0100, 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;

If it works for Matt, that looks reasonable to me.

> > There's probably some register in the chipset that tells us where the
> > MMIO aperture starts.  The best thing to do would be to read that
> > register, use it to initialize irongate_mem, and use that as the MMIO
> > aperture.
> 
> Surely there is the register, namely IRONGATE0->pci_mem, but it's
> basically write-only for us as it contains utter crap on bootup.
> 
> > But I don't know where to look in the chipset, and it looks like the
> > current strategy is to infer the base by looking at BAR assignments of
> > PCI devices.  Can you try the patch below (based on v4.17-rc1) and
> > save the dmesg and /proc/iomem and /proc/ioports contents?  I'm
> > guessing at some things here, so I added a few debug printks, too.
> 
> No, the strategy was to do PCI resource allocations from scratch,
> minimizing MMIO aperture to save as much RAM as possible in 4Gb
> memory configuration. That's what all that hackery with bus sizing
> was for. We pretended that irongate is sort of non-standard p2p bridge
> (which is almost true wrt internal alpha ev6 "host bridge"),
> called pci_bus_size_bridges() for it, then moved calculated MMIO
> window up to 4G boundary and then did normal "assign unassigned".
> However, it was broken long time ago in a more subtle way - even in
> Matt's dmesg from working 3.13 kernels AGP framebuffer resource ended
> up either unassigned or in the wrong place. This is relatively harmless
> if you don't use graphics though. Not sure how to fix that, this
> "root bridge" approach looks rather 

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

[Ivan Kokshaysky]

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;


> There's probably some register in the chipset that tells us where the
> MMIO aperture starts.  The best thing to do would be to read that
> register, use it to initialize irongate_mem, and use that as the MMIO
> aperture.

Surely there is the register, namely IRONGATE0->pci_mem, but it's
basically write-only for us as it contains utter crap on bootup.

> But I don't know where to look in the chipset, and it looks like the
> current strategy is to infer the base by looking at BAR assignments of
> PCI devices.  Can you try the patch below (based on v4.17-rc1) and
> save the dmesg and /proc/iomem and /proc/ioports contents?  I'm
> guessing at some things here, so I added a few debug printks, too.

No, the strategy was to do PCI resource allocations from scratch,
minimizing MMIO aperture to save as much RAM as possible in 4Gb
memory configuration. That's what all that hackery with bus sizing
was for. We pretended that irongate is sort of non-standard p2p bridge
(which is almost true wrt internal alpha ev6 "host bridge"),
called pci_bus_size_bridges() for it, then moved calculated MMIO
window up to 4G boundary and then did normal "assign unassigned".
However, it was broken long time ago in a more subtle way - even in
Matt's dmesg from working 3.13 kernels AGP framebuffer resource ended
up either unassigned or in the wrong place. This is relatively harmless
if you don't use graphics though. Not sure how to fix that, this
"root bridge" approach looks rather limiting to me.
--
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

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

[Bjorn Helgaas]

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.

There's probably some register in the chipset that tells us where the
MMIO aperture starts.  The best thing to do would be to read that
register, use it to initialize irongate_mem, and use that as the MMIO
aperture.

But I don't know where to look in the chipset, and it looks like the
current strategy is to infer the base by looking at BAR assignments of
PCI devices.  Can you try the patch below (based on v4.17-rc1) and
save the dmesg and /proc/iomem and /proc/ioports contents?  I'm
guessing at some things here, so I added a few debug printks, too.


diff --git a/arch/alpha/kernel/sys_nautilus.c b/arch/alpha/kernel/sys_nautilus.c
index ff4f54b86c7f..093ad6e5c75f 100644
--- a/arch/alpha/kernel/sys_nautilus.c
+++ b/arch/alpha/kernel/sys_nautilus.c
@@ -189,10 +189,14 @@ extern void pcibios_claim_one_bus(struct pci_bus *);
 
 static struct resource irongate_io = {
.name   = "Irongate PCI IO",
+   .start  = 0,
+   .end= 0x,
.flags  = IORESOURCE_IO,
 };
 static struct resource irongate_mem = {
.name   = "Irongate PCI MEM",
+   .start  = 0,
+   .end= 0x,
.flags  = IORESOURCE_MEM,
 };
 static struct resource busn_resource = {
@@ -208,7 +212,6 @@ nautilus_init_pci(void)
struct pci_controller *hose = hose_head;
struct pci_host_bridge *bridge;
struct pci_bus *bus;
-   struct pci_dev *irongate;
unsigned long bus_align, bus_size, pci_mem;
unsigned long memtop = max_low_pfn << PAGE_SHIFT;
int ret;
@@ -217,8 +220,8 @@ nautilus_init_pci(void)
if (!bridge)
return;
 
-   pci_add_resource(>windows, _resource);
-   pci_add_resource(>windows, _resource);
+   pci_add_resource(>windows, _io);
+   pci_add_resource(>windows, _mem);
pci_add_resource(>windows, _resource);
bridge->dev.parent = NULL;
bridge->sysdata = hose;
@@ -237,33 +240,30 @@ nautilus_init_pci(void)
bus = hose->bus = bridge->bus;
pcibios_claim_one_bus(bus);
 
-   irongate = pci_get_domain_bus_and_slot(pci_domain_nr(bus), 0, 0);
-   bus->self = irongate;
-   bus->resource[0] = _io;
-   bus->resource[1] = _mem;
-
pci_bus_size_bridges(bus);
 
-   /* IO port range. */
-   bus->resource[0]->start = 0;
-   bus->resource[0]->end = 0x;
-
+   printk("bus->resource[1] %pR\n", >resource[1]);
/* Set up PCI memory range - limit is hardwired to 0x,
   base must be at aligned to 16Mb. */
bus_align = bus->resource[1]->start;
bus_size = bus->resource[1]->end + 1 - bus_align;
if (bus_align < 0x100UL)
bus_align = 0x100UL;
+   printk("bus_align %#lx bus_size %#lx\n", bus_align, bus_size);
 

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

[Matt Turner]

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!


dmesg-1-36e097a8a297
Description: Binary data


dmesg-2-f75b99d5a77d
Description: Binary data


dmesg-3-d56dbf5bab8c
Description: Binary data


lspci
Description: Binary data


dmesg-patched-4.17
Description: Binary data

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

[Bjorn Helgaas]

Hi Matt,

First of all, sorry about breaking Nautilus, and thanks very much for
tracking it down to this commit.

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.

Coincidentally, Christoph is replacing CONFIG_PCI_BUS_ADDR_T_64BIT
with CONFIG_ARCH_DMA_ADDR_T_64BIT, but I think that change is a no-op
with respect to the problem you're seeing.

[1] https://lkml.kernel.org/r/20180415145947.1248-10-...@lst.de
--
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

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

[Matt Turner]

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?
--
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