I don't think it's sufficient, actually. We regularly see machines where devices point into e820_reserved memory above 1 MB - because it's a platform device or because firmware (e.g. smm) is touching the device. I think Bjorn's fix is great for .34, but longer term I think we need to structure the code to actually handle reserved regions differently from occupied/forbidden regions.
"Jesse Barnes" <[email protected]> wrote:
>On Mon, 26 Apr 2010 14:44:50 -0700
>"H. Peter Anvin" <[email protected]> wrote:
>
>> >
>> > Agreed. The trickier part is handling any platform devices that
>> > request_resource against that space. But maybe we don't need to do
>> > anything special; just making sure we avoid it in the PCI "BIOS" code
>> > as Bjorn did may be sufficient.
>> >
>>
>> Why is that hard? If a platform device does a request_resource against
>> that space, it's a request for specific address space and it should be
>> granted.
>
>I was thinking if we made it a special resource type we'd have to
>change any platform drivers to use it; i.e. it wouldn't be
>IORESOURCE_MEM or IORESOURCE_IO but IORESOURCE_DRAGONS. That way it
>wouldn't be part of the normal resource space.
>
>But that's definitely overkill. I think Bjorn's fix is sufficient.
>
>--
>Jesse Barnes, Intel Open Source Technology Center
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Sorry, sounds like we're talking about a few different things here:
1) devices which sit in e820 reserved space (whether at < 1M or > 1M)
2) devices which sit in e820 ram or other space below 1M
3) how to hand out space from the 0-1M region
Bjorn's patch fixes (3) so that regular PCI devices don't get space
there, which makes sense.
Some devices may be in the special region, but were pointed there by
the BIOS. Generally this should be ok, so drivers requesting this
space should be allowed to get at it, but we should avoid putting
anything else there.
And below it sounds like you're talking about (1). If so, then yes I
guess we need a solution there, which will allow drivers to bind to
these "reserved" devices, even though the BIOS has marked them as off
limits, at least as far as e820 goes.
So perhaps both (1) and (2) could be put into a new, special IO
resource space, or could use a new flag, since "busy" doesn't really
reflect what's going on there very well, as Bjorn pointed out.
Jesse
On Mon, 26 Apr 2010 16:02:57 -0700
"H. Peter Anvin" <[email protected]> wrote:
> I don't think it's sufficient, actually. We regularly see machines where devices point into e820_reserved memory above 1 MB - because it's a platform device or because firmware (e.g. smm) is touching the device. I think Bjorn's fix is great for .34, but longer term I think we need to structure the code to actually handle reserved regions differently from occupied/forbidden regions.
>
> "Jesse Barnes" <[email protected]> wrote:
>
> >On Mon, 26 Apr 2010 14:44:50 -0700
> >"H. Peter Anvin" <[email protected]> wrote:
> >
> >> >
> >> > Agreed. The trickier part is handling any platform devices that
> >> > request_resource against that space. But maybe we don't need to do
> >> > anything special; just making sure we avoid it in the PCI "BIOS" code
> >> > as Bjorn did may be sufficient.
> >> >
> >>
> >> Why is that hard? If a platform device does a request_resource against
> >> that space, it's a request for specific address space and it should be
> >> granted.
> >
> >I was thinking if we made it a special resource type we'd have to
> >change any platform drivers to use it; i.e. it wouldn't be
> >IORESOURCE_MEM or IORESOURCE_IO but IORESOURCE_DRAGONS. That way it
> >wouldn't be part of the normal resource space.
> >
> >But that's definitely overkill. I think Bjorn's fix is sufficient.
> >
> >--
> >Jesse Barnes, Intel Open Source Technology Center
>
--
Jesse Barnes, Intel Open Source Technology Center
> Sorry, sounds like we're talking about a few different things here:
> 1) devices which sit in e820 reserved space (whether at < 1M or > 1M)
> 2) devices which sit in e820 ram or other space below 1M
> 3) how to hand out space from the 0-1M region
>
> Bjorn's patch fixes (3) so that regular PCI devices don't get space
> there, which makes sense.
>
> Some devices may be in the special region, but were pointed there by
> the BIOS. Generally this should be ok, so drivers requesting this
> space should be allowed to get at it, but we should avoid putting
> anything else there.
>
> And below it sounds like you're talking about (1). If so, then yes I
> guess we need a solution there, which will allow drivers to bind to
> these "reserved" devices, even though the BIOS has marked them as off
> limits, at least as far as e820 goes.
>
> So perhaps both (1) and (2) could be put into a new, special IO
> resource space, or could use a new flag, since "busy" doesn't really
> reflect what's going on there very well, as Bjorn pointed out.
>
> Jesse
Properly done, these aren't separate cases at all.
The E820 interface as specified doesn't reserve the address space below 1
MB, because it is legacy space -- which is another way of saying "everyone
already knows to reserve it." The Right Thing[TM] to do is simply to
modify the data output by E820 to reserve all non-memory space below 1 MB;
this can (and should) be done in platform-specific initialization code to
allow overrides.
Once that is done, both your (2) and (3) cases are nothing but special
subcases of (1). That's what I would like to see as the right solution,
but it is clearly too late to do that in .34.
Bjorn's solution is very attractive for .34 since it is so simple, but
it's not a complete solution.
-hpa
> Sorry, sounds like we're talking about a few different things here:
> 1) devices which sit in e820 reserved space (whether at < 1M or > 1M)
> 2) devices which sit in e820 ram or other space below 1M
> 3) how to hand out space from the 0-1M region
>
> Bjorn's patch fixes (3) so that regular PCI devices don't get space
> there, which makes sense.
>
> Some devices may be in the special region, but were pointed there by
> the BIOS. Generally this should be ok, so drivers requesting this
> space should be allowed to get at it, but we should avoid putting
> anything else there.
>
> And below it sounds like you're talking about (1). If so, then yes I
> guess we need a solution there, which will allow drivers to bind to
> these "reserved" devices, even though the BIOS has marked them as off
> limits, at least as far as e820 goes.
>
> So perhaps both (1) and (2) could be put into a new, special IO
> resource space, or could use a new flag, since "busy" doesn't really
> reflect what's going on there very well, as Bjorn pointed out.
>
> Jesse
Properly done, these aren't separate cases at all.
The E820 interface as specified doesn't reserve the address space below 1
MB, because it is legacy space -- which is another way of saying "everyone
already knows to reserve it." The Right Thing[TM] to do is simply to
modify the data output by E820 to reserve all non-memory space below 1 MB;
this can (and should) be done in platform-specific initialization code to
allow overrides.
Once that is done, both your (2) and (3) cases are nothing but special
subcases of (1). That's what I would like to see as the right solution,
but it is clearly too late to do that in .34.
Bjorn's solution is very attractive for .34 since it is so simple, but
it's not a complete solution.
-hpa
On Mon, 26 Apr 2010 16:49:55 -0700
"H. Peter Anvin" <[email protected]> wrote:
> > Sorry, sounds like we're talking about a few different things here:
> > 1) devices which sit in e820 reserved space (whether at < 1M or > 1M)
> > 2) devices which sit in e820 ram or other space below 1M
> > 3) how to hand out space from the 0-1M region
> >
> > Bjorn's patch fixes (3) so that regular PCI devices don't get space
> > there, which makes sense.
> >
> > Some devices may be in the special region, but were pointed there by
> > the BIOS. Generally this should be ok, so drivers requesting this
> > space should be allowed to get at it, but we should avoid putting
> > anything else there.
> >
> > And below it sounds like you're talking about (1). If so, then yes I
> > guess we need a solution there, which will allow drivers to bind to
> > these "reserved" devices, even though the BIOS has marked them as off
> > limits, at least as far as e820 goes.
> >
> > So perhaps both (1) and (2) could be put into a new, special IO
> > resource space, or could use a new flag, since "busy" doesn't really
> > reflect what's going on there very well, as Bjorn pointed out.
> >
> > Jesse
>
> Properly done, these aren't separate cases at all.
>
> The E820 interface as specified doesn't reserve the address space below 1
> MB, because it is legacy space -- which is another way of saying "everyone
> already knows to reserve it." The Right Thing[TM] to do is simply to
> modify the data output by E820 to reserve all non-memory space below 1 MB;
> this can (and should) be done in platform-specific initialization code to
> allow overrides.
>
> Once that is done, both your (2) and (3) cases are nothing but special
> subcases of (1). That's what I would like to see as the right solution,
> but it is clearly too late to do that in .34.
>
> Bjorn's solution is very attractive for .34 since it is so simple, but
> it's not a complete solution.
Glad we agree. As I said (and echoing Bjorn), I think it would be best
to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
We want and need to do allocations from the special region, so we
should mark it as such.
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 26 Apr 2010, Jesse Barnes wrote:
>
> Glad we agree. As I said (and echoing Bjorn), I think it would be best
> to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
> We want and need to do allocations from the special region, so we
> should mark it as such.
I think Bjorn's patch to pcibios_align_resource() is really good and
clever, and I think it should take care of the need for IORESOURCE_BUSY,
no? We do want to let devices that are _already_ allocated there insert
their resources, it's just that we never want to allocate new ones in the
low 1M region.
Do we actually have a regression left with Bjorn's patch?
Linus
On Mon, 26 Apr 2010 18:27:27 -0700 (PDT)
Linus Torvalds <[email protected]> wrote:
>
>
> On Mon, 26 Apr 2010, Jesse Barnes wrote:
> >
> > Glad we agree. As I said (and echoing Bjorn), I think it would be best
> > to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
> > We want and need to do allocations from the special region, so we
> > should mark it as such.
>
> I think Bjorn's patch to pcibios_align_resource() is really good and
> clever, and I think it should take care of the need for IORESOURCE_BUSY,
> no? We do want to let devices that are _already_ allocated there insert
> their resources, it's just that we never want to allocate new ones in the
> low 1M region.
>
> Do we actually have a regression left with Bjorn's patch?
No, I think we're covered. But it sounded like Peter was also
concerned about making new allocations from the 1M space, which would
mean we'd need something other than the IORESOURCE_BUSY bit. But maybe
Bjorn's patch plus simply removing the IORESOURCE_BUSY line is
sufficient for that. The downside there is that it doesn't clearly
communicate the special nature of the 1M region.
--
Jesse Barnes, Intel Open Source Technology Center
On 04/26/2010 06:27 PM, Linus Torvalds wrote:
>
>
> On Mon, 26 Apr 2010, Jesse Barnes wrote:
>>
>> Glad we agree. As I said (and echoing Bjorn), I think it would be best
>> to reserve this space in a way that doesn't just use IORESOURCE_BUSY.
>> We want and need to do allocations from the special region, so we
>> should mark it as such.
>
> I think Bjorn's patch to pcibios_align_resource() is really good and
> clever, and I think it should take care of the need for IORESOURCE_BUSY,
> no? We do want to let devices that are _already_ allocated there insert
> their resources, it's just that we never want to allocate new ones in the
> low 1M region.
case A:
bus 0: --- bus X --- device Y
if the BIOS only assign range to to BUS X bridge with 0xB0000, and
device Y is not assigned. then with Bojorn's patch, device Y can not
get right resource allocated on first try.
>
> Do we actually have a regression left with Bjorn's patch?
also find one AMD system:
[ 6.960006] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 6.984225] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-06])
[ 7.023528] pci_root PNP0A03:00: host bridge window [io 0x0000-0x03af]
[ 7.024014] pci_root PNP0A03:00: host bridge window [io 0x03b0-0x03bb]
[ 7.028005] pci_root PNP0A03:00: host bridge window [io 0x03bc-0x03bf]
[ 7.032005] pci_root PNP0A03:00: host bridge window [io 0x03c0-0x03df]
[ 7.036005] pci_root PNP0A03:00: host bridge window [io 0x03e0-0xefff]
[ 7.040011] pci_root PNP0A03:00: host bridge window [mem 0xd8000000-0xe7ffffff]
[ 7.044005] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfe9fffff]
[ 7.048005] pci_root PNP0A03:00: host bridge window [mem 0xfec00000-0xfed0ffff]
[ 7.052005] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[ 7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]
[ 0.000000] BIOS-e820: 0000000000000100 - 0000000000098c00 (usable)
[ 0.000000] BIOS-e820: 0000000000098c00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000d7fa0000 (usable)
[ 0.000000] BIOS-e820: 00000000d7fae000 - 00000000d7fb0000 (reserved)
[ 0.000000] BIOS-e820: 00000000d7fb0000 - 00000000d7fbe000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000d7fbe000 - 00000000d7ff0000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000d7ff0000 - 00000000f0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000008028000000 (usable)
pci assign unassign code could use range like [mem 0xfed20000-0xffffffff] wrongly.
YH
On Monday 26 April 2010 07:41:55 pm Yinghai wrote:
> On 04/26/2010 06:27 PM, Linus Torvalds wrote:
> > Do we actually have a regression left with Bjorn's patch?
After the pcibios_align_resource() patch, I'm not aware of any regressions.
But let's double-check this:
> also find one AMD system:
> [ 7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]
> ...
> pci assign unassign code could use range like [mem 0xfed20000-0xffffffff] wrongly.
I agree, it's very unlikely that it's safe to put PCI devices all the
way up to 0xffffffff. I suspect this might be fixed by d558b483d5a,
which computes the end of the bridge window using _MAX rather than _LEN.
See https://bugzilla.kernel.org/show_bug.cgi?id=15480#c15 for an example
similar to the one above: we originally thought the window was
[mem 0xcff00000-0xffffffff], but d558b483d5a changes that to
[mem 0xcff00000-0xfebfffff], which matches what Windows found.
Yinghai, can you take a look at your AMD system again with a kernel that
includes d558b483d5a, and see whether we still have a problem? If we
*do* still have a problem, please open a bugzilla and attach a dmesg log
with ACPI resource info collected with the debug patch here:
https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5
Bjorn
On 04/28/2010 12:06 PM, Bjorn Helgaas wrote:
> On Wednesday 28 April 2010 11:14:45 am Yinghai Lu wrote:
>> Never mind, for 2.6.34 your patch should be good enough.
>
> Uh, OK.
>
> I'm not trying to be a nuisance, but if there's a machine where
> we think there's a bridge window like [mem 0xfed20000-0xffffffff],
> I want to fix it, even if you think it's "good enough for 2.6.34."
>
> I was hoping you could specifically confirm that "yes, that AMD
> machine was fixed by d558b483d5a," or else give me some more
> information that would help me figure out what's going on.
[ 0.000000] BIOS-e820: 0000000000000100 - 0000000000098c00 (usable)
[ 0.000000] BIOS-e820: 0000000000098c00 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000d7fa0000 (usable)
[ 0.000000] BIOS-e820: 00000000d7fae000 - 00000000d7fb0000 (reserved)
[ 0.000000] BIOS-e820: 00000000d7fb0000 - 00000000d7fbe000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000d7fbe000 - 00000000d7ff0000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000d7ff0000 - 00000000f0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000008028000000 (usable)
[ 6.960006] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[ 6.984225] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-06])
[ 7.023528] pci_root PNP0A03:00: host bridge window [io 0x0000-0x03af]
[ 7.024014] pci_root PNP0A03:00: host bridge window [io 0x03b0-0x03bb]
[ 7.028005] pci_root PNP0A03:00: host bridge window [io 0x03bc-0x03bf]
[ 7.032005] pci_root PNP0A03:00: host bridge window [io 0x03c0-0x03df]
[ 7.036005] pci_root PNP0A03:00: host bridge window [io 0x03e0-0xefff]
[ 7.040011] pci_root PNP0A03:00: host bridge window [mem 0xd8000000-0xe7ffffff]
[ 7.044005] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfe9fffff]
[ 7.048005] pci_root PNP0A03:00: host bridge window [mem 0xfec00000-0xfed0ffff]
[ 7.052005] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
[ 7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]
d7ff0000-efffffff : reserved
d8000000-e7ffffff : PCI Bus 0000:00
d8000000-dfffffff : GART
e8000000-efffffff : PCI Bus 0000:80
fec00000-fed0ffff : PCI Bus 0000:00
fec00000-fec00fff : reserved
fec00000-fec003ff : IOAPIC 0
fed00000-fed003ff : HPET 0
fed10000-fed1ffff : PCI Bus 0000:80
fed20000-ffffffff : PCI Bus 0000:00
fee00000-fee00fff : Local APIC
fee00000-fee00fff : reserved
fefff000-feffffff : pnp 00:0a
ff700000-ffffffff : reserved
ffb80000-fffffffe : pnp 00:06
On Wednesday 28 April 2010 01:10:34 pm Yinghai wrote:
> On 04/28/2010 12:06 PM, Bjorn Helgaas wrote:
> > On Wednesday 28 April 2010 11:14:45 am Yinghai Lu wrote:
> >> Never mind, for 2.6.34 your patch should be good enough.
> >
> > Uh, OK.
> >
> > I'm not trying to be a nuisance, but if there's a machine where
> > we think there's a bridge window like [mem 0xfed20000-0xffffffff],
> > I want to fix it, even if you think it's "good enough for 2.6.34."
> >
> > I was hoping you could specifically confirm that "yes, that AMD
> > machine was fixed by d558b483d5a," or else give me some more
> > information that would help me figure out what's going on.
I can see this is going nowhere. The information below is essentially
just what you already posted, and I'm sorry, but it's not enough for
me to fix anything. Can you tell me the model and BIOS version? Maybe
I can find another one somewhere and do my own poking around.
What I'd like to know is (a) what Windows reports as PCI bus resources,
and (b) what the Linux dmesg looks like with the patch here:
https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5
CONFIG_ACPI_DEBUG=y and the arguments "acpi.debug_level=0x00010000
acpi.debug_layer=0x00000100".
Bjorn
> [ 0.000000] BIOS-e820: 0000000000000100 - 0000000000098c00 (usable)
> [ 0.000000] BIOS-e820: 0000000000098c00 - 00000000000a0000 (reserved)
> [ 0.000000] BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000d7fa0000 (usable)
> [ 0.000000] BIOS-e820: 00000000d7fae000 - 00000000d7fb0000 (reserved)
> [ 0.000000] BIOS-e820: 00000000d7fb0000 - 00000000d7fbe000 (ACPI data)
> [ 0.000000] BIOS-e820: 00000000d7fbe000 - 00000000d7ff0000 (ACPI NVS)
> [ 0.000000] BIOS-e820: 00000000d7ff0000 - 00000000f0000000 (reserved)
> [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
> [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
> [ 0.000000] BIOS-e820: 00000000ff700000 - 0000000100000000 (reserved)
> [ 0.000000] BIOS-e820: 0000000100000000 - 0000008028000000 (usable)
>
> [ 6.960006] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
> [ 6.984225] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-06])
> [ 7.023528] pci_root PNP0A03:00: host bridge window [io 0x0000-0x03af]
> [ 7.024014] pci_root PNP0A03:00: host bridge window [io 0x03b0-0x03bb]
> [ 7.028005] pci_root PNP0A03:00: host bridge window [io 0x03bc-0x03bf]
> [ 7.032005] pci_root PNP0A03:00: host bridge window [io 0x03c0-0x03df]
> [ 7.036005] pci_root PNP0A03:00: host bridge window [io 0x03e0-0xefff]
> [ 7.040011] pci_root PNP0A03:00: host bridge window [mem 0xd8000000-0xe7ffffff]
> [ 7.044005] pci_root PNP0A03:00: host bridge window [mem 0xf0000000-0xfe9fffff]
> [ 7.048005] pci_root PNP0A03:00: host bridge window [mem 0xfec00000-0xfed0ffff]
> [ 7.052005] pci_root PNP0A03:00: host bridge window [mem 0x000a0000-0x000bffff]
> [ 7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]
>
>
> d7ff0000-efffffff : reserved
> d8000000-e7ffffff : PCI Bus 0000:00
> d8000000-dfffffff : GART
> e8000000-efffffff : PCI Bus 0000:80
> fec00000-fed0ffff : PCI Bus 0000:00
> fec00000-fec00fff : reserved
> fec00000-fec003ff : IOAPIC 0
> fed00000-fed003ff : HPET 0
> fed10000-fed1ffff : PCI Bus 0000:80
> fed20000-ffffffff : PCI Bus 0000:00
> fee00000-fee00fff : Local APIC
> fee00000-fee00fff : reserved
> fefff000-feffffff : pnp 00:0a
> ff700000-ffffffff : reserved
> ffb80000-fffffffe : pnp 00:06
>
>
Yinghai, ping, do you have any more information about this?
On Tuesday 27 April 2010 09:11:10 am Bjorn Helgaas wrote:
> On Monday 26 April 2010 07:41:55 pm Yinghai wrote:
> But let's double-check this:
>
> > also find one AMD system:
> > [ 7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]
> > ...
> > pci assign unassign code could use range like [mem 0xfed20000-0xffffffff] wrongly.
>
> I agree, it's very unlikely that it's safe to put PCI devices all the
> way up to 0xffffffff. I suspect this might be fixed by d558b483d5a,
> which computes the end of the bridge window using _MAX rather than _LEN.
>
> See https://bugzilla.kernel.org/show_bug.cgi?id=15480#c15 for an example
> similar to the one above: we originally thought the window was
> [mem 0xcff00000-0xffffffff], but d558b483d5a changes that to
> [mem 0xcff00000-0xfebfffff], which matches what Windows found.
>
> Yinghai, can you take a look at your AMD system again with a kernel that
> includes d558b483d5a, and see whether we still have a problem? If we
> *do* still have a problem, please open a bugzilla and attach a dmesg log
> with ACPI resource info collected with the debug patch here:
> https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5
>
> Bjorn
>
Never mind, for 2.6.34 your patch should be good enough.
On 04/28/2010 09:07 AM, Bjorn Helgaas wrote:
> Yinghai, ping, do you have any more information about this?
>
> On Tuesday 27 April 2010 09:11:10 am Bjorn Helgaas wrote:
>
>> On Monday 26 April 2010 07:41:55 pm Yinghai wrote:
>> But let's double-check this:
>>
>>
>>> also find one AMD system:
>>> [ 7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]
>>> ...
>>> pci assign unassign code could use range like [mem 0xfed20000-0xffffffff] wrongly.
>>>
>> I agree, it's very unlikely that it's safe to put PCI devices all the
>> way up to 0xffffffff. I suspect this might be fixed by d558b483d5a,
>> which computes the end of the bridge window using _MAX rather than _LEN.
>>
>> See https://bugzilla.kernel.org/show_bug.cgi?id=15480#c15 for an example
>> similar to the one above: we originally thought the window was
>> [mem 0xcff00000-0xffffffff], but d558b483d5a changes that to
>> [mem 0xcff00000-0xfebfffff], which matches what Windows found.
>>
>> Yinghai, can you take a look at your AMD system again with a kernel that
>> includes d558b483d5a, and see whether we still have a problem? If we
>> *do* still have a problem, please open a bugzilla and attach a dmesg log
>> with ACPI resource info collected with the debug patch here:
>> https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5
>>
>> Bjorn
>>
>>
>
>
On Wednesday 28 April 2010 11:14:45 am Yinghai Lu wrote:
> Never mind, for 2.6.34 your patch should be good enough.
Uh, OK.
I'm not trying to be a nuisance, but if there's a machine where
we think there's a bridge window like [mem 0xfed20000-0xffffffff],
I want to fix it, even if you think it's "good enough for 2.6.34."
I was hoping you could specifically confirm that "yes, that AMD
machine was fixed by d558b483d5a," or else give me some more
information that would help me figure out what's going on.
Bjorn
> On 04/28/2010 09:07 AM, Bjorn Helgaas wrote:
> > Yinghai, ping, do you have any more information about this?
> >
> > On Tuesday 27 April 2010 09:11:10 am Bjorn Helgaas wrote:
> >
> >> On Monday 26 April 2010 07:41:55 pm Yinghai wrote:
> >> But let's double-check this:
> >>
> >>
> >>> also find one AMD system:
> >>> [ 7.056011] pci_root PNP0A03:00: host bridge window [mem 0xfed20000-0xffffffff]
> >>> ...
> >>> pci assign unassign code could use range like [mem 0xfed20000-0xffffffff] wrongly.
> >>>
> >> I agree, it's very unlikely that it's safe to put PCI devices all the
> >> way up to 0xffffffff. I suspect this might be fixed by d558b483d5a,
> >> which computes the end of the bridge window using _MAX rather than _LEN.
> >>
> >> See https://bugzilla.kernel.org/show_bug.cgi?id=15480#c15 for an example
> >> similar to the one above: we originally thought the window was
> >> [mem 0xcff00000-0xffffffff], but d558b483d5a changes that to
> >> [mem 0xcff00000-0xfebfffff], which matches what Windows found.
> >>
> >> Yinghai, can you take a look at your AMD system again with a kernel that
> >> includes d558b483d5a, and see whether we still have a problem? If we
> >> *do* still have a problem, please open a bugzilla and attach a dmesg log
> >> with ACPI resource info collected with the debug patch here:
> >> https://bugzilla.kernel.org/show_bug.cgi?id=15533#c5
> >>
> >> Bjorn
> >>
> >>
> >
> >
>
>