[lkml]   [2010]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[PATCH] x86/PCI: never allocate PCI MMIO resources below BIOS_END
On Wednesday 21 April 2010 01:31:20 pm Andy Isaacson wrote:
> On Tue, Apr 20, 2010 at 10:33:50PM -0700, Yinghai wrote:
> > Update e820 at first, and later put them resource tree.
> > Reserved that early, will not be allocated to unassigned PCI BAR
> >
> > v3: remove probe_roms() that is not needed, because whole range is reserved
> > already
> Test booted this patch series on the problematic t3400, seems to work
> fine. dmesg attached to bug 15744.

Thanks for testing (again). I'm not confident that this series is
going to be successful, so I started looking for other approaches.

I can't reproduce the exact problem you're seeing, but in my
kludged-up attempt, the patch below is enough to keep us from
assigning the space below 1MB to a device.

Would you guys (Andy & Andy, what a coincidence :-)) mind giving
it a try? This is intended to work on top of current upstream,
with no other patches required.


commit 7fb707eb97fdf6dc4fa4b127f127f8d00223afc7
Author: Bjorn Helgaas <>
Date: Fri Apr 23 15:22:10 2010 -0600

x86/PCI: never allocate PCI MMIO resources below BIOS_END

When we move a PCI device or assign resources to a device not configured
by the BIOS, we want to avoid the BIOS region below 1MB. Note that if the
BIOS places devices below 1MB, we leave them there.


Signed-off-by: Bjorn Helgaas <>

diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index 46fd43f..97da2ba 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -72,6 +72,9 @@ pcibios_align_resource(void *data, const struct resource *res,
return start;
if (start & 0x300)
start = (start + 0x3ff) & ~0x3ff;
+ } else if (res->flags & IORESOURCE_MEM) {
+ if (start < BIOS_END)
+ start = BIOS_END;
return start;

 \ /
  Last update: 2010-04-24 01:07    [W:0.220 / U:7.872 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site