aboutsummaryrefslogtreecommitdiffstats
path: root/arch/i386/kernel/efi.c
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@osdl.org>2006-02-22 15:50:30 -0800
committerGreg Kroah-Hartman <gregkh@suse.de>2006-03-23 14:35:14 -0800
commitb408cbc704352eccee301e1103b23203ba1c3a0e (patch)
tree5d0262537d6b3a3406aec61298520c045af9be8b /arch/i386/kernel/efi.c
parent75cde0e25787c1af341a128b350c36df24e5397d (diff)
downloadkernel_samsung_aries-b408cbc704352eccee301e1103b23203ba1c3a0e.zip
kernel_samsung_aries-b408cbc704352eccee301e1103b23203ba1c3a0e.tar.gz
kernel_samsung_aries-b408cbc704352eccee301e1103b23203ba1c3a0e.tar.bz2
[PATCH] PCI: resource address mismatch
On Tue, 21 Feb 2006, Ivan Kokshaysky wrote: > There are two bogus entries in the BIOS memory map table which are > conflicting with a prefetchable memory range of the AGP bridge: > > BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) > BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > > 0000:00:02.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) (prog-if 00 [Normal decode]) > Flags: bus master, fast devsel, latency 0 > Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 > I/O behind bridge: 0000c000-0000cfff > Memory behind bridge: e7e00000-e7efffff > Prefetchable memory behind bridge: fec00000-ffcfffff > ^^^^^^^^^^^^^^^^^ Yes. However, it's pretty clear that the e820 entries are there for a reason. Probably they are a hack by the BIOS maintainers to keep Windows from stomping/moving that region, exactly because they want to keep the bridge where it is (or, it's actually for the BIOS itself - the BIOS tables are a horrid mess, and BIOS engineers are pretty hacky people: they'll add random entries to make their own broken algorithms do the "right thing"). > Starting from 2.6.13, kernel tries to resolve that sort of conflicts, > so that prefetch window of the bridge and the framebuffer memory behind > it get moved to 0x10000000. I think we could (and probably should) solve this another way: consider the ACPI "reserved regions" from the e820 map exactly the same way that we do other ACPI hints - they should restrict _new_ allocations, but not impact stuff we figure out on our own. Basically, right now we assign _unassigned_ resources at "fs_initcall" time. If we were to add in the e820 "reserved region" stuff before that (but after we've done PCI discovery), we'd probably do the right thing. Right now we do the e820 reserved regions very early indeed: we call "register_memory()" from setup_arch(). We could move at least part of it (the part that registers the resources) down a bit. Here's a test-patch. I'm not saying we should absolutely do this, but it might be interesting to try... Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: <bjk@luxsci.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'arch/i386/kernel/efi.c')
-rw-r--r--arch/i386/kernel/efi.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/arch/i386/kernel/efi.c b/arch/i386/kernel/efi.c
index aeabb41..7ec6cfa 100644
--- a/arch/i386/kernel/efi.c
+++ b/arch/i386/kernel/efi.c
@@ -543,7 +543,7 @@ efi_initialize_iomem_resources(struct resource *code_resource,
if ((md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT)) >
0x100000000ULL)
continue;
- res = alloc_bootmem_low(sizeof(struct resource));
+ res = kzalloc(sizeof(struct resource), GFP_ATOMIC);
switch (md->type) {
case EFI_RESERVED_TYPE:
res->name = "Reserved Memory";