Bug 11103 - Can't use framebuffer or vesa Xorg with two memory modules
Can't use framebuffer or vesa Xorg with two memory modules
Status: CLOSED CODE_FIX
Product: Memory Management
Classification: Unclassified
Component: Other
All Linux
: P1 normal
Assigned To: Andrew Morton
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-16 14:47 UTC by Yannick Roehlly
Modified: 2010-05-19 21:37 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.27rc8
Tree: Mainline
Regression: No


Attachments
Kernel configuration (84.15 KB, text/plain)
2008-09-13 11:19 UTC, Yannick Roehlly
Details
Dmesg output without passing mem parameter (45.60 KB, text/plain)
2008-09-13 11:20 UTC, Yannick Roehlly
Details
/proc/iomem content (1.94 KB, text/plain)
2008-09-13 11:21 UTC, Yannick Roehlly
Details
/proc/mtrr content (199 bytes, text/plain)
2008-09-13 11:21 UTC, Yannick Roehlly
Details
Dmesg output passing mem=2048M parameter (44.99 KB, text/plain)
2008-09-13 11:22 UTC, Yannick Roehlly
Details
dmesg from booting with 2.6.27-rc8 kernel (62.24 KB, text/plain)
2008-09-30 11:09 UTC, Yannick Roehlly
Details
Boot log (from dmesg) with "debug pci=earlydump" passed to kernel 2.6.29.1 (78.38 KB, text/plain)
2009-04-10 19:13 UTC, Yannick Roehlly
Details
Result of "lspci -tv" (1.80 KB, text/plain)
2009-04-10 19:14 UTC, Yannick Roehlly
Details
Result of lspci -vvxxxx with 2GB of RAM (220.72 KB, text/plain)
2009-04-10 19:15 UTC, Yannick Roehlly
Details
Result of "lspci -vvxxxx" with 4GB of RAM (220.91 KB, text/plain)
2009-04-10 19:16 UTC, Yannick Roehlly
Details
Boot log (from dmesg) with "debug pci=earlydump" passed to kernel 2.9.30 tip.git (86.68 KB, text/plain)
2009-04-12 19:47 UTC, Yannick Roehlly
Details
Result of "lspci -vvxxx" with kernel 2.9.30 tip.git and 4GB RAM (59.03 KB, text/plain)
2009-04-12 19:51 UTC, Yannick Roehlly
Details
Xorg log with radeon driver and kernel 2.9.30 tip.git (16.16 KB, text/plain)
2009-04-12 19:53 UTC, Yannick Roehlly
Details
Xorg log with radeonhd driver and kernel 2.9.30 tip.git (8.94 KB, text/plain)
2009-04-12 19:55 UTC, Yannick Roehlly
Details
don't allocate pref mem 32bit above 4g (7.62 KB, patch)
2009-04-13 21:23 UTC, Yinghai Lu
Details | Diff
Boot log (from dmesg) with "debug pci=earlydump" passed to kernel 2.9.30 tip.git (103.49 KB, text/plain)
2009-04-14 18:20 UTC, Yannick Roehlly
Details
pci start early (706 bytes, patch)
2009-04-14 18:32 UTC, Yinghai Lu
Details | Diff
Boot log (from dmesg) with "debug pci=earlydump" passed to kernel 2.9.30 tip with the 2 patches. It works! (103.95 KB, text/plain)
2009-04-14 20:05 UTC, Yannick Roehlly
Details

Description Yannick Roehlly 2008-07-16 14:47:35 UTC
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.
Comment 1 Andrew Morton 2008-07-16 14:58:25 UTC
eek, Jesse, help!
Comment 2 Yannick Roehlly 2008-07-21 12:45:24 UTC
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
Comment 3 Yannick Roehlly 2008-08-01 13:05:18 UTC
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
Comment 4 Alexey Dobriyan 2008-09-13 01:24:44 UTC
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)
Comment 5 Yannick Roehlly 2008-09-13 11:18:04 UTC
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
Comment 6 Yannick Roehlly 2008-09-13 11:19:06 UTC
Created attachment 17762 [details]
Kernel configuration
Comment 7 Yannick Roehlly 2008-09-13 11:20:16 UTC
Created attachment 17763 [details]
Dmesg output without passing mem parameter
Comment 8 Yannick Roehlly 2008-09-13 11:21:20 UTC
Created attachment 17764 [details]
/proc/iomem content
Comment 9 Yannick Roehlly 2008-09-13 11:21:42 UTC
Created attachment 17765 [details]
/proc/mtrr content
Comment 10 Yannick Roehlly 2008-09-13 11:22:22 UTC
Created attachment 17766 [details]
Dmesg output passing mem=2048M parameter
Comment 11 D. Hugh Redelmeier 2008-09-28 13:18:05 UTC
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
Comment 12 Yannick Roehlly 2008-09-30 11:07:26 UTC
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
Comment 13 Yannick Roehlly 2008-09-30 11:09:01 UTC
Created attachment 18118 [details]
dmesg from booting with 2.6.27-rc8 kernel
Comment 14 Yinghai Lu 2009-03-31 00:37:35 UTC
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
Comment 15 Yannick Roehlly 2009-04-10 19:09:17 UTC
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
Comment 16 Yannick Roehlly 2009-04-10 19:13:43 UTC
Created attachment 20928 [details]
Boot log (from dmesg) with "debug pci=earlydump" passed to kernel 2.6.29.1
Comment 17 Yannick Roehlly 2009-04-10 19:14:19 UTC
Created attachment 20929 [details]
Result of "lspci -tv"
Comment 18 Yannick Roehlly 2009-04-10 19:15:14 UTC
Created attachment 20930 [details]
Result of lspci -vvxxxx with 2GB of RAM
Comment 19 Yannick Roehlly 2009-04-10 19:16:22 UTC
Created attachment 20931 [details]
Result of "lspci -vvxxxx" with 4GB of RAM
Comment 20 Yinghai Lu 2009-04-10 20:28:04 UTC
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
Comment 21 Yinghai Lu 2009-04-11 03:29:41 UTC
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, &region, 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;
 }
Comment 22 Yannick Roehlly 2009-04-11 21:15:37 UTC
Hi,

Do you need me to test these patches? If yes, against which kernel?

Sincerely,

Yannick
Comment 23 Yinghai Lu 2009-04-11 21:48:01 UTC
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
Comment 24 Yannick Roehlly 2009-04-12 19:45:57 UTC
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
Comment 25 Yannick Roehlly 2009-04-12 19:47:47 UTC
Created attachment 20945 [details]
Boot log (from dmesg) with "debug pci=earlydump" passed to kernel 2.9.30 tip.git
Comment 26 Yannick Roehlly 2009-04-12 19:51:55 UTC
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.
Comment 27 Yannick Roehlly 2009-04-12 19:53:45 UTC
Created attachment 20947 [details]
Xorg log with radeon driver and kernel 2.9.30 tip.git
Comment 28 Yannick Roehlly 2009-04-12 19:55:50 UTC
Created attachment 20948 [details]
Xorg log with radeonhd driver and kernel 2.9.30 tip.git
Comment 29 Yinghai Lu 2009-04-13 01:06:27 UTC
did you try the patch on comment #21?
Comment 30 Yannick Roehlly 2009-04-13 15:20:13 UTC
Yes. Sorry, I meant "the tip.git source" with the patches above. ;-)
Comment 31 Yinghai Lu 2009-04-13 19:36:01 UTC
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
Comment 32 Yinghai Lu 2009-04-13 21:23:15 UTC
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
Comment 33 Yannick Roehlly 2009-04-14 18:05:17 UTC
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
Comment 34 Yannick Roehlly 2009-04-14 18:20:54 UTC
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.
Comment 35 Yinghai Lu 2009-04-14 18:27:40 UTC
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.
Comment 36 Yinghai Lu 2009-04-14 18:32:15 UTC
Created attachment 20979 [details]
pci start early

please test this patch in addition to "don't allocate pref mem 32bit above 4g"
Comment 37 Yannick Roehlly 2009-04-14 20:05:12 UTC
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
Comment 38 xado 2009-08-23 18:41:10 UTC
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 :(
Comment 39 xado 2009-08-23 18:56:02 UTC
I forget this https://bugs.launchpad.net/ubuntu/+source/linux/+bug/316079 . I hope it'll help.
Comment 40 Yannick Roehlly 2009-08-23 19:25:56 UTC
Just wait for the 2.6.31 kernel (which is at its 7th RC) and you'll no more need patches.
Comment 41 xado 2009-08-23 20:22:09 UTC
wow thanks a lots. bye
Comment 42 Alan 2010-01-19 19:46:39 UTC
Can folks confirm this is in 2.6.31 ?
Comment 43 xado 2010-01-27 20:39:16 UTC
I confirm it. I'm using Ubuntu 9.10 karmic koala with kernel version 2.6.31 ;)
Comment 44 Yannick Roehlly 2010-05-19 21:13:20 UTC
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

Note You need to log in before you can comment on or make changes to this bug.