Make sure We can reject wrong size from BIOS.
https://bugzilla.kernel.org/show_bug.cgi?id=16009
Yannick found that video does not work with 2.6.34
the root cause:
BIOS assigned wrong range to pci bridge. and before 2.6.34 kernel will
just get range that is needed.
for 2.6.34.
| d65245c PCI: don't shrink bridge resources
will try to range size is bigger than old one.
(used by boot stage multi-try to get big BAR size for pci bridge,
and pcie hotplug to get big range)
So try to 0 for old size for pci bridge in this boot stage case.
Reported-by: Yannick <[email protected]>
Analyzed-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Yinghai Lu <[email protected]>
---
arch/microblaze/pci/pci-common.c | 1 +
arch/mn10300/unit-asb2305/pci-asb2305.c | 1 +
arch/powerpc/kernel/pci-common.c | 1 +
arch/x86/pci/i386.c | 1 +
4 files changed, 4 insertions(+)
Index: linux-2.6/arch/x86/pci/i386.c
===================================================================
--- linux-2.6.orig/arch/x86/pci/i386.c
+++ linux-2.6/arch/x86/pci/i386.c
@@ -136,6 +136,7 @@ static void __init pcibios_allocate_bus_
* child resource allocations in this
* range.
*/
+ r->start = r->end = 0;
r->flags = 0;
}
}
Index: linux-2.6/arch/microblaze/pci/pci-common.c
===================================================================
--- linux-2.6.orig/arch/microblaze/pci/pci-common.c
+++ linux-2.6/arch/microblaze/pci/pci-common.c
@@ -1277,6 +1277,7 @@ void pcibios_allocate_bus_resources(stru
printk(KERN_WARNING "PCI: Cannot allocate resource region "
"%d of PCI bridge %d, will remap\n", i, bus->number);
clear_resource:
+ res->start = res->end = 0;
res->flags = 0;
}
Index: linux-2.6/arch/mn10300/unit-asb2305/pci-asb2305.c
===================================================================
--- linux-2.6.orig/arch/mn10300/unit-asb2305/pci-asb2305.c
+++ linux-2.6/arch/mn10300/unit-asb2305/pci-asb2305.c
@@ -117,6 +117,7 @@ static void __init pcibios_allocate_bus_
* Invalidate the resource to prevent
* child resource allocations in this
* range. */
+ r->start = r->end = 0;
r->flags = 0;
}
}
Index: linux-2.6/arch/powerpc/kernel/pci-common.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/pci-common.c
+++ linux-2.6/arch/powerpc/kernel/pci-common.c
@@ -1309,6 +1309,7 @@ void pcibios_allocate_bus_resources(stru
printk(KERN_WARNING "PCI: Cannot allocate resource region "
"%d of PCI bridge %d, will remap\n", i, bus->number);
clear_resource:
+ res->start = res->end = 0;
res->flags = 0;
}
Le Thursday 03 June 2010 22:43:03 Yinghai Lu, vous avez écrit :
> Make sure We can reject wrong size from BIOS.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=16009
> Yannick found that video does not work with 2.6.34
Hi Yinghai,
I tested the 2nd version of your patch. I still works.
Cheers,
Yannick
On Thu, 03 Jun 2010 13:43:03 -0700
Yinghai Lu <[email protected]> wrote:
>
> Make sure We can reject wrong size from BIOS.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=16009
> Yannick found that video does not work with 2.6.34
>
> the root cause:
> BIOS assigned wrong range to pci bridge. and before 2.6.34 kernel will
> just get range that is needed.
> for 2.6.34.
> | d65245c PCI: don't shrink bridge resources
> will try to range size is bigger than old one.
> (used by boot stage multi-try to get big BAR size for pci bridge,
> and pcie hotplug to get big range)
>
> So try to 0 for old size for pci bridge in this boot stage case.
>
> Reported-by: Yannick <[email protected]>
> Analyzed-by: Bjorn Helgaas <[email protected]>
> Signed-off-by: Yinghai Lu <[email protected]>
>
Bjorn, are you ok with this version? It would probably help to have
some comments here too (I can add them), indicating that we'll try to
reassign the resource later, rather than just ignoring it as the
existing comment implies.
--
Jesse Barnes, Intel Open Source Technology Center
On 06/08/2010 03:48 PM, Bjorn Helgaas wrote:
> On Tuesday, June 08, 2010 03:43:50 pm Jesse Barnes wrote:
>
> In this case, the aperture *size* from the BIOS is actually OK, but
> the beginning of the aperture overlaps system memory. With Yinghai's
> patch, we reduce the size and move the start. Windows was able to
> just move the start of the aperture and preserve the original
> 0x20000000 size (but I think it had to move something else out of
> the way).
are you sure? that looks more aggressive.
Yinghai
On Tuesday, June 08, 2010 03:43:50 pm Jesse Barnes wrote:
> On Thu, 03 Jun 2010 13:43:03 -0700
> Yinghai Lu <[email protected]> wrote:
>
> >
> > Make sure We can reject wrong size from BIOS.
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=16009
> > Yannick found that video does not work with 2.6.34
> >
> > the root cause:
> > BIOS assigned wrong range to pci bridge. and before 2.6.34 kernel will
> > just get range that is needed.
> > for 2.6.34.
> > | d65245c PCI: don't shrink bridge resources
> > will try to range size is bigger than old one.
> > (used by boot stage multi-try to get big BAR size for pci bridge,
> > and pcie hotplug to get big range)
> >
> > So try to 0 for old size for pci bridge in this boot stage case.
> >
> > Reported-by: Yannick <[email protected]>
> > Analyzed-by: Bjorn Helgaas <[email protected]>
> > Signed-off-by: Yinghai Lu <[email protected]>
> >
>
> Bjorn, are you ok with this version? It would probably help to have
> some comments here too (I can add them), indicating that we'll try to
> reassign the resource later, rather than just ignoring it as the
> existing comment implies.
I guess I'm ok with it. I can't make much sense out of the changelog,
and I don't really understand how the reallocation stuff works.
In this case, the aperture *size* from the BIOS is actually OK, but
the beginning of the aperture overlaps system memory. With Yinghai's
patch, we reduce the size and move the start. Windows was able to
just move the start of the aperture and preserve the original
0x20000000 size (but I think it had to move something else out of
the way).
Bjorn
On Tuesday, June 08, 2010 05:36:33 pm Yinghai Lu wrote:
> On 06/08/2010 03:48 PM, Bjorn Helgaas wrote:
> > On Tuesday, June 08, 2010 03:43:50 pm Jesse Barnes wrote:
> >
> > In this case, the aperture *size* from the BIOS is actually OK, but
> > the beginning of the aperture overlaps system memory. With Yinghai's
> > patch, we reduce the size and move the start. Windows was able to
> > just move the start of the aperture and preserve the original
> > 0x20000000 size (but I think it had to move something else out of
> > the way).
>
> are you sure? that looks more aggressive.
I don't have the machine and can't be 100% sure, but based on what
Yannic reported here: https://bugzilla.kernel.org/show_bug.cgi?id=16009#c11,
it looks like Windows moved that aperture.
I haven't used it myself, but possibly a program like SIV
(http://rh-software.com/) would give more detailed information
about what Windows is doing.
Bjorn
Le Thursday 10 June 2010 01:30:31 Bjorn Helgaas, vous avez ?crit :
> On Tuesday, June 08, 2010 05:36:33 pm Yinghai Lu wrote:
> > On 06/08/2010 03:48 PM, Bjorn Helgaas wrote:
> > > On Tuesday, June 08, 2010 03:43:50 pm Jesse Barnes wrote:
> > >
> > > In this case, the aperture *size* from the BIOS is actually OK, but
> > > the beginning of the aperture overlaps system memory. With Yinghai's
> > > patch, we reduce the size and move the start. Windows was able to
> > > just move the start of the aperture and preserve the original
> > > 0x20000000 size (but I think it had to move something else out of
> > > the way).
> >
> > are you sure? that looks more aggressive.
>
> I don't have the machine and can't be 100% sure, but based on what
> Yannic reported here:
> https://bugzilla.kernel.org/show_bug.cgi?id=16009#c11, it looks like
> Windows moved that aperture.
>
> I haven't used it myself, but possibly a program like SIV
> (http://rh-software.com/) would give more detailed information
> about what Windows is doing.
Hi Bjorn,
I don't know if it's useful, but here some output of SIV concerning PCI and
the Radeon card.
Yannick
On Friday, June 11, 2010 02:44:42 am Yannick Roehlly wrote:
> Le Thursday 10 June 2010 01:30:31 Bjorn Helgaas, vous avez ?crit :
> > On Tuesday, June 08, 2010 05:36:33 pm Yinghai Lu wrote:
> > > On 06/08/2010 03:48 PM, Bjorn Helgaas wrote:
> > > > On Tuesday, June 08, 2010 03:43:50 pm Jesse Barnes wrote:
> > > >
> > > > In this case, the aperture *size* from the BIOS is actually OK, but
> > > > the beginning of the aperture overlaps system memory. With Yinghai's
> > > > patch, we reduce the size and move the start. Windows was able to
> > > > just move the start of the aperture and preserve the original
> > > > 0x20000000 size (but I think it had to move something else out of
> > > > the way).
> > >
> > > are you sure? that looks more aggressive.
> >
> > I don't have the machine and can't be 100% sure, but based on what
> > Yannic reported here:
> > https://bugzilla.kernel.org/show_bug.cgi?id=16009#c11, it looks like
> > Windows moved that aperture.
> >
> > I haven't used it myself, but possibly a program like SIV
> > (http://rh-software.com/) would give more detailed information
> > about what Windows is doing.
>
> Hi Bjorn,
>
> I don't know if it's useful, but here some output of SIV concerning PCI and
> the Radeon card.
Can SIV generate a big dump of similar output for all devices at once?
Then I could avoid bugging you for "look at this, look at that," etc :-)
I'm particularly interested in the bridges (the PCIe root ports, in
this case). I think Windows moved the 00:01.0 prefetchable aperture.
We know from the Linux dmesg that the 00:01.0 bridge was initially
configured like this:
pci 0000:00:01.0: PCI bridge to [bus 01-01]
pci 0000:00:01.0: bridge window [io 0x7000-0x9fff]
pci 0000:00:01.0: bridge window [mem 0xfdd00000-0xfddfffff]
pci 0000:00:01.0: bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
Based on https://bugzilla.kernel.org/show_bug.cgi?id=16009#c11, I think
Windows moved the prefetchable aperture:
Plage m?moire: 00000000FDD00000 - 00000000FDDFFFFF
Plage m?moire: 00000000C0000000 - 00000000DFFFFFFF <== moved
Plage d'E/S: 7000 - 9FFF
Note that the aperture size is still 0x20000000.
Since this new [mem 0xc0000000-0xdfffffff] aperture would conflict
with this 00:1c.4 aperture:
pci 0000:00:1c.4: bridge window [mem 0xddf00000-0xdfefffff 64bit pref]
I think it's likely that Windows moved the 1c.4 aperture as well (or
maybe even disabled it, since it leads to buses 06-07, and there are
no devices on those buses).
Bjorn