Bug 11103
eek, Jesse, help! I don't know if it can help, but I tried to use uvesafb (with 2.6.25 and 2.6.26). When trying to modprobe the uvesafb module, I have this error: [ 63.773389] uvesafb: (C) 1988-2005, ATI Technologies Inc. M8201.00, M8201.00, 01.00, OEM: ATI ATOMBIOS(C) 1988-2005, ATI Technologies Inc. M8201.00, VBE v3.0 [ 63.797601] uvesafb: VBIOS/hardware supports DDC2 transfers [ 63.859535] uvesafb: monitor limits: vf = 59 Hz, hf = 55 kHz, clk = 88 MHz [ 63.861191] uvesafb: scrolling: redraw [ 63.861191] uvesafb: cannot reserve video memory at 0x40000000 [ 63.861191] uvesafb: probe of uvesafb.0 failed with error -5 I noticed that I have this error on boot: PCI: BIOS Bug: MCFG area at e0000000 is not E820-reserved Also, someone on the Xorg bugzilla made me realize that I'm not sure that the problem occurs because of the two memory modules; as a matter of fact, the problem may be linked with "more than 2Go of RAM". If one day I can have access to another 1Go module, I'll test with 1Go+1Go. Yannick OK, here is what we do: 0. Grab 2.6.27-rc6. 1. Insert all RAM you have 2. boot, check that bug still exists 3. attach .config , /proc/iomem , /proc/mtrr , and, most importantly, full "dmesg" output 4. Do the same for kernel booted with "mem=2048M" boot option appended, if bug do not exist in this case 5. If in 2048M case you still have this bug, lower then number until bug dissapears, and post dmesg from that (like mem=1024M) Hi Alexey, Thank you for considering the problem. Alas, 2.6.27-rc6 doesn't solve the problem. Even using the mem kernel option does not (I tryed 2048, 1024 and 512M). I'll attach the files you need (_4096 means without passing mem option and _2048 means passing the mem=2048M option). I suspect a bios bug. The graphic card (HD3470 customized for Asus) is supposed to be using hypermemory but nowhere in the bios you can set the amount of main memory used by the card. Maybe there's an automatic adjustment? Sincerely, Yannick Created attachment 17762 [details]
Kernel configuration
Created attachment 17763 [details]
Dmesg output without passing mem parameter
Created attachment 17764 [details]
/proc/iomem content
Created attachment 17765 [details]
/proc/mtrr content
Created attachment 17766 [details]
Dmesg output passing mem=2048M parameter
This may be a "nested MTRRs" problem. I cannot tell from the description. Certainly your MTRRs are nested and that makes it hard for X video device driver or the frame buffer driver to change the caching behaviour of the video device buffer. See, for example, http://bugzilla.kernel.org/show_bug.cgi?id=10508 My comment there (#21) explains an approach I suggest you try. Do read the manpage for mtrr-uncover. mtrr-uncover produces the following output for your /proc/mtrr setup $ ./mtrr-uncover --mtrrfile mtrr.sample.kbt17765 Initial MTRR configuration: 1 0x000000000-0x0ffffffff write-back 0 0x0c0000000-0x0ffffffff uncachable 2 0x100000000-0x13fffffff write-back Final MTRR configuration: 1' 0x000000000-0x07fffffff write-back 50' 0x080000000-0x0bfffffff write-back 2 0x100000000-0x13fffffff write-back Commands for /proc/mtrr to make these changes: disable=0 disable=1 base=0x000000000 size=0x080000000 type=write-back base=0x080000000 size=0x040000000 type=write-back Hi. I durst not the --execute option of mtrr-uncover as you say it's dangerous (I don't know if it's dangerous for the hardware or only the system installed on). ;-) Nevertheless, I tested the 2.6.27-rc8 with MTRR_SANITIZER and apparently it "unnestted" the mtrr. Here's the result of mtrr-uncover with this kernel: Initial MTRR configuration: 0 0x000000000-0x07fffffff write-back 1 0x080000000-0x0bfffffff write-back 2 0x100000000-0x13fffffff write-back No changes made. Alas, it does not solve the problem. By the way, I have still a problem of PCI resource allocation, but with a difference: pnp 00:0d: mem resource (0x100000-0xbfffffff) overlaps 0000:00:01.0 BAR 9 (0xbdf00000-0xddefffff), disabling pci 0000:00:01.0: BAR 9: can't allocate resource pci 0000:01:00.0: BAR 0: can't allocate resource I'll attach the full dmesg. Yannick Created attachment 18118 [details]
dmesg from booting with 2.6.27-rc8 kernel
looks like BIOS didn't set mmio range in 00:01.0 for bus 01. [ 0.229460] PCI: 0000:01:00.0 reg 10 32bit mmio: [c0000000, cfffffff] [ 0.229467] PCI: 0000:01:00.0 reg 14 io port: [9000, 90ff] [ 0.229474] PCI: 0000:01:00.0 reg 18 32bit mmio: [fddf0000, fddfffff] [ 0.229495] PCI: 0000:01:00.0 reg 30 32bit mmio: [fddc0000, fdddffff] [ 0.229513] pci 0000:01:00.0: supports D1 [ 0.229515] pci 0000:01:00.0: supports D2 [ 0.229554] PCI: bridge 0000:00:01.0 io port: [7000, 9fff] [ 0.229559] PCI: bridge 0000:00:01.0 32bit mmio: [fdd00000, fddfffff] [ 0.229565] PCI: bridge 0000:00:01.0 64bit mmio pref: [bdf00000, ddefffff] kernel try to let it to use 0x00000140000000-0x0000014fffffff but it failed, [ 0.288837] pci 0000:00:01.0: BAR 9: can't allocate resource [ 0.288837] pci 0000:01:00.0: BAR 0: can't allocate resource can you post: lspci -tv lspci -vvxxxx also boot log with "debug pci=earlydump" also please try tip in http://people.redhat.com/mingo/tip.git/readme.txt Good evening (UTC+0200), I've tested again with kernel 2.6.29.1 and xorg 1.6.0. Now, the framebuffer console works. The vesa xorg driver (2.2.0) also works. But neither the radeon nor the radeonhd do. I'm sorry, I don't know if it's a kernel problem or an Xorg one. I'll attach the dmesg with "debug pci=earlydump", the results of "lspci -vvxxxx" with 2GB and with 4GB, and the result of "lspci -tv". Sincerely, Yannick Created attachment 20928 [details]
Boot log (from dmesg) with "debug pci=earlydump" passed to kernel 2.6.29.1
Created attachment 20929 [details]
Result of "lspci -tv"
Created attachment 20930 [details]
Result of lspci -vvxxxx with 2GB of RAM
Created attachment 20931 [details]
Result of "lspci -vvxxxx" with 4GB of RAM
bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=11103 > > > > > > --- Comment #16 from Yannick <yannick.roehlly@free.fr> 2009-04-10 19:13:43 > --- > Created an attachment (id=20928) > --> (http://bugzilla.kernel.org/attachment.cgi?id=20928) > Boot log (from dmesg) with "debug pci=earlydump" passed to kernel 2.6.29.1 > root cause: when 4G installed. BIOS put ACPI etc need the hole [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009bc00 (usable) [ 0.000000] BIOS-e820: 000000000009bc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e3000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bffa0000 (usable) [ 0.000000] BIOS-e820: 00000000bffa0000 - 00000000bffae000 (ACPI data) [ 0.000000] BIOS-e820: 00000000bffae000 - 00000000bfff0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bfff0000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) so resource will be reserved for 0xbffa0000 - 0xbfff0000 for ACPI 0x100000 - 0xbffa0000 for RAM... then BIOS set [ 0.240007] pci 0000:00:01.0: bridge 64bit mmio pref: [0xbdf00000-0xddefffff] [ 0.237102] pci 0000:01:00.0: reg 10 32bit mmio: [0xc0000000-0xcfffffff] that is conflict with reserved res. so it can not be reserved Kernel. then Kernel try to get range from 0x140000000 ( above the RAM, 5G and above 4g) and set let the bridge to use it, and your ATI cards to use it. but the problem is that your ATI only support 32bit ... solution: 1. get updated BIOS? 2. kernel side: a. reserved return one could use range ( shrinked range ), and set it back to pci bridge? b. or add pci=earlyset like to hack the pci conf in early stage. also in kernel side, we should not assign 64bit range to pci device that only take 32bit pref, it mess up the pci conf. 01:00.0 VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3400 Series (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 19d3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 10 Region 0: Memory at 140000000 (32-bit, prefetchable) [size=256M] Region 1: I/O ports at 9000 [size=256] Region 2: Memory at fddf0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at fddc0000 [disabled] [size=128K] .. 00: 02 10 c4 95 07 01 10 00 00 00 00 03 08 00 00 00 10: 08 00 00 40 01 90 00 00 00 00 df fd 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 d3 19 30: 00 00 dc fd 50 00 00 00 00 00 00 00 0a 01 00 00 40: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 d3 19 YH please check [PATCH] pci: don't assume pref mem io are 64bit Impact: fix bug with some devices one system with 4g installed ( there is 1g hole) when 4G installed. BIOS put ACPI etc need the hole [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009bc00 (usable) [ 0.000000] BIOS-e820: 000000000009bc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e3000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bffa0000 (usable) [ 0.000000] BIOS-e820: 00000000bffa0000 - 00000000bffae000 (ACPI data) [ 0.000000] BIOS-e820: 00000000bffae000 - 00000000bfff0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bfff0000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) so in kernel resource will be reserved for 0xbffa0000 - 0xbfff0000 for ACPI 0x100000 - 0xbffa0000 for RAM... and BIOS set [ 0.240007] pci 0000:00:01.0: bridge 64bit mmio pref: [0xbdf00000-0xddefffff] [ 0.237102] pci 0000:01:00.0: reg 10 32bit mmio: [0xc0000000-0xcfffffff] that is conflict with reserved res. so it can not be reserved Kernel. then Kernel try to get range from 0x140000000 ( above the RAM, 5G and above 4g) and set let the bridge to use it, and ATI cards to use it. but the problem is that ATI only support 32bit ... we should not assign 64bit range to pci device that only take 32bit pref try to set PCI_PREF_RANGE_TYPE_64 in 64bit resource of pci_device (besides in pci_bridge), and make the bus resource only have that bit set when all device under that do support 64bit pref mem then use that flag to decide the max limit for find/request. Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/bus.c | 8 +++++++- drivers/pci/probe.c | 8 ++++++-- drivers/pci/setup-bus.c | 38 ++++++++++++++++++++++++++++---------- 3 files changed, 41 insertions(+), 13 deletions(-) Index: linux-2.6/drivers/pci/bus.c =================================================================== --- linux-2.6.orig/drivers/pci/bus.c +++ linux-2.6/drivers/pci/bus.c @@ -41,9 +41,15 @@ pci_bus_alloc_resource(struct pci_bus *b void *alignf_data) { int i, ret = -ENOMEM; + resource_size_t max = -1; type_mask |= IORESOURCE_IO | IORESOURCE_MEM; + /* don't allocate too high if the pref mem doesn't support 64bit*/ + if ((res->flags & (IORESOURCE_PREFETCH | PCI_PREF_RANGE_TYPE_64)) == + IORESOURCE_PREFETCH) + max = 0xffffffff; + for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) { struct resource *r = bus->resource[i]; if (!r) @@ -62,7 +68,7 @@ pci_bus_alloc_resource(struct pci_bus *b /* Ok, try it out.. */ ret = allocate_resource(r, res, size, r->start ? : min, - -1, align, + max, align, alignf, alignf_data); if (ret == 0) break; Index: linux-2.6/drivers/pci/probe.c =================================================================== --- linux-2.6.orig/drivers/pci/probe.c +++ linux-2.6/drivers/pci/probe.c @@ -193,7 +193,7 @@ int __pci_read_base(struct pci_dev *dev, res->flags |= pci_calc_resource_flags(l) | IORESOURCE_SIZEALIGN; if (type == pci_bar_io) { l &= PCI_BASE_ADDRESS_IO_MASK; - mask = PCI_BASE_ADDRESS_IO_MASK & 0xffff; + mask = PCI_BASE_ADDRESS_IO_MASK & IO_SPACE_LIMIT; } else { l &= PCI_BASE_ADDRESS_MEM_MASK; mask = (u32)PCI_BASE_ADDRESS_MEM_MASK; @@ -237,6 +237,9 @@ int __pci_read_base(struct pci_dev *dev, dev_printk(KERN_DEBUG, &dev->dev, "reg %x 64bit mmio: %pR\n", pos, res); } + + if (res->flags & IORESOURCE_PREFETCH) + res->flags |= PCI_PREF_RANGE_TYPE_64; } else { sz = pci_size(l, sz, mask); @@ -362,7 +365,8 @@ void __devinit pci_read_bridge_bases(str } } if (base <= limit) { - res->flags = (mem_base_lo & PCI_MEMORY_RANGE_TYPE_MASK) | IORESOURCE_MEM | IORESOURCE_PREFETCH; + res->flags = (mem_base_lo & PCI_PREF_RANGE_TYPE_MASK) | + IORESOURCE_MEM | IORESOURCE_PREFETCH; res->start = base; res->end = limit + 0xfffff; dev_printk(KERN_DEBUG, &dev->dev, "bridge %sbit mmio pref: %pR\n", Index: linux-2.6/drivers/pci/setup-bus.c =================================================================== --- linux-2.6.orig/drivers/pci/setup-bus.c +++ linux-2.6/drivers/pci/setup-bus.c @@ -143,6 +143,7 @@ static void pci_setup_bridge(struct pci_ struct pci_dev *bridge = bus->self; struct pci_bus_region region; u32 l, bu, lu, io_upper16; + int pref_mem64; if (pci_is_enabled(bridge)) return; @@ -198,16 +199,22 @@ static void pci_setup_bridge(struct pci_ pci_write_config_dword(bridge, PCI_PREF_LIMIT_UPPER32, 0); /* Set up PREF base/limit. */ + pref_mem64 = 0; bu = lu = 0; pcibios_resource_to_bus(bridge, ®ion, bus->resource[2]); if (bus->resource[2]->flags & IORESOURCE_PREFETCH) { + int width = 8; l = (region.start >> 16) & 0xfff0; l |= region.end & 0xfff00000; - bu = upper_32_bits(region.start); - lu = upper_32_bits(region.end); - dev_info(&bridge->dev, " PREFETCH window: %#016llx-%#016llx\n", - (unsigned long long)region.start, - (unsigned long long)region.end); + if (bus->resource[2]->flags & PCI_PREF_RANGE_TYPE_64) { + pref_mem64 = 1; + bu = upper_32_bits(region.start); + lu = upper_32_bits(region.end); + width = 16; + } + dev_info(&bridge->dev, " PREFETCH window: %#0*llx-%#0*llx\n", + width, (unsigned long long)region.start, + width, (unsigned long long)region.end); } else { l = 0x0000fff0; @@ -215,9 +222,11 @@ static void pci_setup_bridge(struct pci_ } pci_write_config_dword(bridge, PCI_PREF_MEMORY_BASE, l); - /* Set the upper 32 bits of PREF base & limit. */ - pci_write_config_dword(bridge, PCI_PREF_BASE_UPPER32, bu); - pci_write_config_dword(bridge, PCI_PREF_LIMIT_UPPER32, lu); + if (pref_mem64) { + /* Set the upper 32 bits of PREF base & limit. */ + pci_write_config_dword(bridge, PCI_PREF_BASE_UPPER32, bu); + pci_write_config_dword(bridge, PCI_PREF_LIMIT_UPPER32, lu); + } pci_write_config_word(bridge, PCI_BRIDGE_CONTROL, bus->bridge_ctl); } @@ -255,8 +264,11 @@ static void pci_bridge_check_ranges(stru pci_read_config_dword(bridge, PCI_PREF_MEMORY_BASE, &pmem); pci_write_config_dword(bridge, PCI_PREF_MEMORY_BASE, 0x0); } - if (pmem) + if (pmem) { b_res[2].flags |= IORESOURCE_MEM | IORESOURCE_PREFETCH; + if ((pmem & PCI_PREF_RANGE_TYPE_MASK) == PCI_PREF_RANGE_TYPE_64) + b_res[2].flags |= PCI_PREF_RANGE_TYPE_64; + } } /* Helper function for sizing routines: find first available @@ -336,6 +348,7 @@ static int pbus_size_mem(struct pci_bus resource_size_t aligns[12]; /* Alignments from 1Mb to 2Gb */ int order, max_order; struct resource *b_res = find_free_bus_resource(bus, type); + unsigned int mem64_mask = 0; if (!b_res) return 0; @@ -344,6 +357,9 @@ static int pbus_size_mem(struct pci_bus max_order = 0; size = 0; + if (type & IORESOURCE_PREFETCH) + mem64_mask = PCI_PREF_RANGE_TYPE_64; + list_for_each_entry(dev, &bus->devices, bus_list) { int i; @@ -372,6 +388,8 @@ static int pbus_size_mem(struct pci_bus aligns[order] += align; if (order > max_order) max_order = order; + if (r->flags & IORESOURCE_PREFETCH) + mem64_mask &= r->flags & PCI_PREF_RANGE_TYPE_64; } } @@ -395,7 +413,7 @@ static int pbus_size_mem(struct pci_bus } b_res->start = min_align; b_res->end = size + min_align - 1; - b_res->flags |= IORESOURCE_STARTALIGN; + b_res->flags |= IORESOURCE_STARTALIGN | mem64_mask; return 1; } Hi, Do you need me to test these patches? If yes, against which kernel? Sincerely, Yannick bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=11103 > > > > > > --- Comment #22 from Yannick <yannick.roehlly@free.fr> 2009-04-11 21:15:37 > --- > Hi, > > Do you need me to test these patches? If yes, against which kernel? > please apply the patches with tip http://people.redhat.com/mingo/tip.git/readme.txt Hi, I've compiled the tip.git source but it does not work. The radeon driver fails with "No valid linear framebuffer address" and the radeonhd driver fails with "No Video RAM detected". I'll attach the same file as last time (plus the Xorg logs). Yannick Created attachment 20945 [details]
Boot log (from dmesg) with "debug pci=earlydump" passed to kernel 2.9.30 tip.git
Created attachment 20946 [details]
Result of "lspci -vvxxx" with kernel 2.9.30 tip.git and 4GB RAM
"lspci -tv" gives the same results as before.
Created attachment 20947 [details]
Xorg log with radeon driver and kernel 2.9.30 tip.git
Created attachment 20948 [details]
Xorg log with radeonhd driver and kernel 2.9.30 tip.git
did you try the patch on comment #21? Yes. Sorry, I meant "the tip.git source" with the patches above. ;-) bugzilla-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=11103 > > > > > > --- Comment #30 from Yannick <yannick.roehlly@free.fr> 2009-04-13 15:20:13 > --- > Yes. Sorry, I meant "the tip.git source" with the patches above. ;-) > can you enable CONFIG_PCI_DEBUG=y in your .config Created attachment 20966 [details]
don't allocate pref mem 32bit above 4g
please try this on top of tip and send out boot log.
please make sure
CONFIG_PCI_DEBUG=y
is in your .config
Hi, I recompiled tip kernel with your patch (applied with "git apply") and with enabling CONFIG_PCI_DEBUG. I have the same results as my previous try with git kernel: "No valid linear framebuffer address" or "No Video RAM detected" depending on the Xorg driver used. I'll attach the dmesg output but it doesn't seem to give more information thant before. Is there something to do at boot time to enable the PCI debug messages? Yannick Created attachment 20978 [details]
Boot log (from dmesg) with "debug pci=earlydump" passed to kernel 2.9.30 tip.git
Oops, I had forgotten to pass the "debug" parameter to the kernel.
Here is the real boot log with PCI debug messages.
good, that is what we want: [ 0.280410] pci 0000:00:01.0: BAR 9: can't allocate mem resource [0x140000000-0xffffffff] [ 0.280470] pci 0000:01:00.0: BAR 0: can't allocate mem resource [0x100000000-0xfddfffff] [ 0.280527] pci 0000:00:01.0: PCI bridge, secondary bus 0000:01 [ 0.280577] pci 0000:00:01.0: IO window: 0x7000-0x9fff [ 0.280627] pci 0000:00:01.0: MEM window: 0xfdd00000-0xfddfffff [ 0.280678] pci 0000:00:01.0: PREFETCH window: disabled it will not allocate that wrong pref range. Created attachment 20979 [details]
pci start early
please test this patch in addition to "don't allocate pref mem 32bit above 4g"
Created attachment 20984 [details]
Boot log (from dmesg) with "debug pci=earlydump" passed to kernel 2.9.30 tip with the 2 patches. It works!
You're the one!!! With your two patches, Xorg works.
Here's the boot log of the working kernel.
Thank you soooo much.
Yannick
hi to everybody, sorry for my question, but when this fix will be include in the kernel main branch. It's a bit stressful waiting recompiling all times :( I forget this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/316079 . I hope it'll help. Just wait for the 2.6.31 kernel (which is at its 7th RC) and you'll no more need patches. wow thanks a lots. bye Can folks confirm this is in 2.6.31 ? I confirm it. I'm using Ubuntu 9.10 karmic koala with kernel version 2.6.31 ;) Hi, Filling another bug on the kernel bugzilla, I found that this one had never been closed, whereas I has been corrected since kernel 2.6.31. I don't know the policy here and if a "submitter" should close a bug, but this one should definitely be. Sincerely, Yannick |
Latest working kernel version: none Earliest failing kernel version: 2.6.25 Distribution: Debian Sid Hardware Environment: Asus M51Se laptop, T8300, ATI Radeon HD3470 Problem Description: I've got an Asus M51Se laptop. If I boot with only one 2Go memory module, everything is fine. I can boot with the kernel framebuffer console and I can launch Xorg using the vesa driver. But if I boot with two modules (2Go+2Go or 2Go+1Go) I can't use neither the framebuffer console (the screen remains black even if the machine boots) nor the vesa driver (the screen is "scrambled"). Early in the boot process, when booting with two modules I have this error: [ 0.292314] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report [ 0.292317] PCI: Cannot allocate resource region 9 of bridge 0000:00:01.0 [ 0.292387] PCI: Cannot allocate resource region 0 of device 0000:01:00.0 [ 0.354395] PCI: Failed to allocate mem resource #9:10000000@0 for 0000:00:01.0 [ 0.354441] PCI: Failed to allocate mem resource #0:10000000@0 for 0000:01:00.0 where device 0000:01:00.0 is the graphic card. I've tested the "pci=routeirq" but without success. I've tested both 64bits and 32bits kernels (on corresponding distributions). What makes me suspect a kernel problem is that using Freebsd (with Freesbee livecd) the vesa Xorg driver works. Note also that when using two modules, the Bios uses them in dual-channel mode (I can't change that). As I'm not used to bug reporting about the kernel, there must be a lot of information missing. Feel free to ask what information you need, I'll plug a second memory module to bring them to you. Sincerely, Yannick PS: I filled this bug under "memory management" but I'm not sure it's the correct place.