MTRR is not properly setup on Intel Northbridge Chipset (P35, X38, X48) with more than 3GB RAM and with Memory Remapping Enabled

[Greg King]

Binary package hint: xorg-driver-fglrx

In Hardy Heron (8.04). MTRR is improperly configured and causes a hard lock of X and the entire computer (I can't use force the kernel into Raw Keyboard Input Mode) when it attempts to use the display driver - fglrx (when using memory remapping). Current specs of the system:
Intel Q9450 (Stock speeds)
Asus P5K-E/Wifi
4GB of PC2-8500 (G.Skill Memory)
HIS 3870 (512MB 3870 AMD/ATi Graphics Card)

Further, the Xorg log shows the following Warnings and Errors:
(WW) RADEON(0): Failed to set up write-combining range (0xd0000000,0x10000000)
..
(WW) RADEON(0): Direct rendering disabled
(EE) RADEON(0): Acceleration initialization failed
(II) RADEON(0): Acceleration disabled

When I disable memory remapping (in the BIOS), MTRR is configured differently and fglrx no longer crashes but I only have access to a little over 3GB of memory.
gking@bender:~$ cat /proc/meminfo
MemTotal: 3355540 kB

Relevant Info:
========
gking@bender:~$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

===================
With Memory Remapping Enabled:
gking@bender:~$ cat /proc/mtrr
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 256MB: write-back, count=1

====================
With Memory Remapping Disabled:
gking@bender:~$ cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1

============================
gking@bender:~$ apt-cache policy xorg-driver-fglrx
xorg-driver-fglrx:
  Installed: 1:7.1.0-8-3+2.6.24.12-16.34
  Candidate: 1:7.1.0-8-3+2.6.24.12-16.34
  Version table:
 *** 1:7.1.0-8-3+2.6.24.12-16.34 0
        500 http://ca.archive.ubuntu.com hardy/restricted Packages
        100 /var/lib/dpkg/status

[Greg King (greg-james-king)]

This question has the same problem (but with different graphics card):
https://answers.launchpad.net/ubuntu/+question/31200

[gnuser (bfteamit)]

This is the problem about:
https://answers.launchpad.net/ubuntu/+question/31200

1) Ubuntu 8.04 64 bit updated
2) xorg-driver-fglrx 1:7.1.0-8-3+2.6.24.12-17.36 0
3) I expected fglrx to work
4) I tried to install the new ATI driver 8.3/8.4 on Ubuntu 8.04 64 bit in many different ways, but never works and gets stuck with a black screen, with no error message. (32 bit version works regularly!!!)
No changes by disabling memory mapping in the bios!!!

HW:
Mb: ASUS p5k-e
Ram: 8 GB TeamGroup
Graphics card: ASUS 3850 512 MB

my /proc/mtrr on Ubuntu 8.04 - 32 bit - (fglrx works):
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=8192MB: write-back, count=1
reg03: base=0x200000000 (8192MB), size= 512MB: write-back, count=1
reg04: base=0x220000000 (8704MB), size= 256MB: write-back, count=1

my /proc/mtrr on Ubuntu 8.04 - 64 bit - *updated* (fglrx doesn't work):
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=8192MB: write-back, count=1
reg03: base=0x200000000 (8192MB), size= 512MB: write-back, count=1
reg04: base=0x220000000 (8704MB), size= 256MB: write-back, count=1

[gnuser (bfteamit)]

Nothing else is strange apart from these log lines:

kernel log: [fglrx] Maximum main memory to use for locked dma buffers: 7766 MBytes.
kernel log: [fglrx] ASYNCIO init succeed!
kernel log: [fglrx] PAT is enabled successfully!
kernel log: [fglrx] module loaded - fglrx 8.47.3 [Feb 25 2008] on minor 0

kernel log: mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining

daemon log: gdm[5828]: GLib-CRITICAL: g_key_file_get_string: assertion `key_file != NULL' failed
daemon log: gdm[5828]: GLib-CRITICAL: g_key_file_free: assertion `key_file != NULL' failed

[gnuser (bfteamit)]

ah, forgot

CPU E6750 Intel core duo
BIOS asus bios 1012

[Kurt Peterschmidt (kurtpete)]

I'm having a similar issue with a Dell Optiplex 755 with 4gb and an amd64 install of Hardy. The installed video card is an ATI hd2400xt with 256mb. Using the fglrx driver results in an immediate crash at the start of X with 4gb in the machine. Remove 1 stick of ram (leaving 3gb) and all is well.

cat /proc/mtrr with 4gb in the machine gives:

reg00: base=0x00000000 ( 0MB), size=65536MB: write-back, count=1
reg01: base=0xcff00000 (3327MB), size= 1MB: uncachable, count=1
reg02: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg03: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1

...and with 3gb gives:

reg00: base=0x00000000 ( 0MB), size=65536MB: write-back, count=1
reg01: base=0xbef00000 (3055MB), size= 1MB: uncachable, count=1
reg02: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1

very little in the Xorg log file, when the crash occurs except for:

(EE) fglrx(0): [drm] failed to remove DRM signal handler
(II) fglrx(0): [drm] removed 1 reserved context for kernel
(II) fglrx(0): [drm] unmapping 8192 bytes of SAREA 0x2000 at 0x7f4a97a13000
(II) fglrx(0): [drm] Closed DRM master.

I have the most recent BIOS update available from Dell, and I've also tried the kernel in hardy-proposed (2.6.24-17-generic). The issue has persisted. I also have the most recent fglrx driver (8.4) installed through envyNG.

A similarly spec'd machine with the 32-bit install of Hardy does not experience this issue.

This appears to either be a bios or a kernel issue, I'm not sure which...

[Mahmoud Al-Qudsi (mqudsi)]

Same issues here, VESA works fine; Ubuntu's fglrx drivers don't work; and manually installing the latest 8.5 drivers from ATi doesn't work either.

Specs:

E6750 on an ASUS Maximus Formula
4GB DDR2 RAM
ATI HD 3870

[Mahmoud Al-Qudsi (mqudsi)]

This is not an ATi issue.

Same problem with nVidia & 4GB of RAM, also caused by MTRR issues
http://www.nvnews.net/vbulletin/showthread.php?t=89781

I should add that I get the same behavior on Fedora 9 x64 as well.

[Rich Hewitt (rich-e-hewitt)]

I have the same problem. Stock Dell Optiplex 755 Quad Core 2.4GHz with 4GB and ATI HD2400XT.

8.04 64bit (updated)
2.6.24-17-generic

[spontex (spontex)]

I have the same problem.
Ubuntu 8.04 64bits / 4GB RAM / Wubi / ATI proprietary driver = black screen.
Tried again yesterday and got a white screen.

[spontex (spontex)]

Forgot to add that it works fine without the ATI restricted driver or with the 32bits version.
I have a MSI P35 motherboard.

[Greg King (greg-james-king)]

I think we might need to remove the ASUS part of the title of this bug report. Because it looks like its not restricted to just ASUS motherboards.

[Greg King (greg-james-king)]

I'm going to attempt running the X server through gdb and see if I can get a backtrace.

[Greg King (greg-james-king)]

Okay. So running /usr/bin/Xorg through gdb failed (I was unable to get a backtrace). I was following instructions from https://wiki.ubuntu.com/DebuggingXorg . I ran it through strace and used the output option (it is attached to this message).

[Greg King (greg-james-king)]

Here is the updated dmesg for the new kernel (first line is uname -a).

[Greg King (greg-james-king)]

cat /proc/mtrr is attached (with memory remapping enabled)

[Greg King (greg-james-king)]

With memory remapping disabled:
gking@bender:~$ cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1

Attached is dmesg with memory remapping disabled

[GhOsHe (ghoshe)]

I've found a possible "solution", check it in:

https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/226672

Saludos!

[Greg King (greg-james-king)]

Does anyone know why the mtrr tables aren't setup correctly? Further, is it appropriate to reconfigure the mtrr tables by hand (I assume that if you misconfigure it ... you might crash your computer or worse)?

[GhOsHe (ghoshe)]

That's a very good question Greg :P

On the other hand, reconfiguring mttr tables won't damage your hardware, but can slow down the computer like a 8086, or cause a total crash (without BSOD xD), requiring you to reset manually.

I needed two crashes before finding a compatible mtrr table.

It's very important to disable all the old registers before adding new ones, or you will crash again.

I apologize for my poor English, i have it a little bit rusty.

Good luck.

[Greg King (greg-james-king)]

I think the issue that we are seeing, is related to the kernel thinking that the graphics card memory is uncachable. If the mtrr tables are changed such that the memory at d0000000 is set to write-back rather than uncachable

So:
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
is changed to
reg00: base=0xd0000000 (3328MB), size= 256MB: write-back, count=1

This guess is due to the line starred below (***) ... found by sudo lspci -vv
and what appears to be the congruent line in the mtrr tables.

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 3870 (prog-if 00 [VGA controller])
        Subsystem: Hightech Information System Ltd. Unknown device 2003
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 16
*** Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M] ***
        Region 2: Memory at fe8e0000 (64-bit, non-prefetchable) [size=64K]
        Region 4: I/O ports at c000 [size=256]
        Expansion ROM at fe8c0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express Legacy Endpoint IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag+
                Device: Latency L0s <4us, L1 unlimited
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
                Link: Supported Speed 2.5Gb/s, Width x16, ASPM L0s L1, Port 0
                Link: Latency L0s <64ns, L1 <1us
                Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
                Link: Speed 2.5Gb/s, Width x16
        Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
                Address: 0000000000000000 Data: 0000

[Greg King (greg-james-king)]

I also don't know whether it should be write-back or write-combining.

[Rich Hewitt (rich-e-hewitt)]

Is this the same bug?

https://bugs.launchpad.net/linux/+bug/210780

the suggestion is its a bios problem.

I have:

reg00: base=0x00000000 ( 0MB), size=65536MB: write-back, count=1
reg01: base=0xcff00000 (3327MB), size= 1MB: uncachable, count=1
reg02: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg03: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1

and

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 2400 XT (prog-if 00 [VGA controller])
 Subsystem: Dell Unknown device 0d02
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0, Cache Line Size: 64 bytes
 Interrupt: pin A routed to IRQ 11
 Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M]
 Region 2: Memory at fe9f0000 (64-bit, non-prefetchable) [size=64K]

and

[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009e400 (usable)
[ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000cfdff800 (usable)
[ 0.000000] BIOS-e820: 00000000cfdff800 - 00000000cfe53c00 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000cfe53c00 - 00000000cfe55c00 (ACPI data)
[ 0.000000] BIOS-e820: 00000000cfe55c00 - 00000000d0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fed00400 (reserved)
[ 0.000000] BIOS-e820: 00000000fed20000 - 00000000feda0000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fef00000 (reserved)
[ 0.000000] BIOS-e820: 00000000ffb00000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000000128000000 (usable)

however, I've not been able to get very far with my attempts to manually construct an appropriate mtrr.

[Greg King (greg-james-king)]

I think this is the same bug ... but with a different graphics card. I've added a quick post to the bug report and hopefully they'll notice that this also affects the people using fglrx drivers.

[Rich Hewitt (rich-e-hewitt)]

I finally have aiglx+compiz running on my Optiplex 755 with 4GB. I have to rewrite the MTRR in /etc/rc.local. I'm not convinced that the mtrr is in any sense optimal, but so far so good.

[Emmett Keyser (ekeyser)]

Rich Hewitt, can you post your mtrr tables fix?

[Rich Hewitt (rich-e-hewitt)]

My /etc/rc.local is below ... for what it's worth ... it's unlikely to be of any use to anyone unless they have exactly the same machine, memory size & gfx card. A better general discussion on how to 'fix' the mtrr is available at:

http://www.rage3d.com/board/showthread.php?t=33821469

-----
echo "disable=0" >| /proc/mtrr
echo "disable=2" >| /proc/mtrr

echo "base=0x00000000 size=0x80000000 type=write-back" >| /proc/mtrr
echo "base=0x80000000 size=0x40000000 type=write-back" >| /proc/mtrr
echo "base=0xC0000000 size=0x10000000 type=write-back" >| /proc/mtrr
echo "base=0xD0000000 size=0x10000000 type=write-combining" >| /proc/mtrr
echo "base=0x100000000 size=0x40000000 type=write-back" >| /proc/mtrr

my original mtrr is listed in a post above if you want to check what the disable commands are changing.

[Emmett Keyser (ekeyser)]

Thank you, sir. Yes I should've mentioned that I have the same exact configuration as you down to the same video card. I've been trying out various mtrr modifications for a couple of days now to no avail. Thought instead that I'd just see if anyone had the same exact config/setup as me instead of me trying to figure this out the hard way.

Btw I tried out your table changes and it worked perfectly.

I had looked at that rage3d.com page before and tried it out. Obviously it needed modifications for it to apply to my system but I guess I was missing something because I wasn't doing it correctly. I'll go back now and see what logic I was missing.

e

[Samuel Cochran (sj26)]

Similar situation:
When I use fglrx with default configuration it blanks the screen and hard locks the system (VTs and network die). I have to disable AIGLX, Composite, Accleration and DRI for it to work at all. If I change VTs it crashes.

I don't have a BIOS option for Memory Re-Mapping so I can't test turning it on/off. I haven't yet tried removing/replacing a RAM stick.

Hardware:
Intel Core 2 Duo E8400 (45nm, 3.0GHz)
2x2GB = 4GB DDR2-800 Kingston
Gigabyte EP35-SD3R motherboard
Sapphire ATI Radeon HD 2400 PRO

sj26@viridis:~/src$ lsb_release -rd
Description: Ubuntu 8.04
Release: 8.04

sj26@viridis:~/src$ uname -a
Linux viridis 2.6.24-18-generic #1 SMP Wed May 28 19:28:38 UTC 2008 x86_64 GNU/Linux

sj26@viridis:~/src$ cat /proc/meminfo
MemTotal: 4053800 kB
MemFree: 3065532 kB
Buffers: 589464 kB
Cached: 217388 kB
SwapCached: 0 kB
Active: 173052 kB
Inactive: 731264 kB
SwapTotal: 1526132 kB
SwapFree: 1526132 kB
Dirty: 12 kB
Writeback: 0 kB
AnonPages: 97472 kB
Mapped: 32640 kB
Slab: 41824 kB
SReclaimable: 24392 kB
SUnreclaim: 17432 kB
PageTables: 7028 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 3553032 kB
Committed_AS: 330552 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 20608 kB
VmallocChunk: 34359717375 kB

sj26@viridis:~/src$ cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg03: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg04: base=0x130000000 (4864MB), size= 256MB: uncachable, count=1
reg05: base=0xcff00000 (3327MB), size= 1MB: uncachable, count=1

For the open-source radeonhd driver which sort-of works I got the same/similar message as my current fglrx setup in the Xorg log:

(WW) fglrx(0): Failed to set up write-combining range (0xd0000000,0x10000000)

I'm using fglrx from the ubuntu restricted drivers package:
sj26@viridis:~/src$ apt-cache show xorg-driver-fglrx
Package: xorg-driver-fglrx
...
Source: linux-restricted-modules-2.6.24 (2.6.24.13-19.42)
Version: 1:7.1.0-8-3+2.6.24.13-19.42
...
MD5sum: d25fed1486a3a70766969a54b24b7800
SHA1: bffc8ce322c7127cbbe443254e517fb3e7b8cf8b
SHA256: d54494b5003acc245c988dcd3573b67316a4f7a685380e3661ef847ff6e09ec3

/etc/X11/xorg.conf:

Section "ServerLayout"
 Identifier "Default Layout"
 Screen 0 "aticonfig-Screen[0]" 0 0
 InputDevice "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
 RgbPath "/etc/X11/rgb"
 ModulePath "/usr/lib/xorg/modules"
 FontPath "/usr/share/fonts/X11/misc"
 FontPath "/usr/share/fonts/X11/100dpi/:unscaled"
 FontPath "/usr/share/fonts/X11/75dpi/:unscaled"
 FontPath "/usr/share/fonts/X11/Type1"
 FontPath "/usr/share/fonts/X11/100dpi"
 FontPath "/usr/share/fonts/X11/75dpi"
EndSection

Section "Module"
EndSection

Section "InputDevice"
 Identifier "Keyboard0"
 Driver "kbd"
EndSection

Section "Monitor"
 Identifier "aticonfig-Monitor[0]"
 Option "VendorName" "ATI Proprietary Driver"
 Option ...

[Samuel Cochran (sj26)]

Update: Removing the second stick of memory "fixes" the problem, but at the cost of 2GB of RAM.

[D. Hugh Redelmeier (hugh-mimosa)]

I wonder if the xorg fix/workaround described here would work: https://bugs.freedesktop.org/show_bug.cgi?id=2750

Description: When WC MTRR is set up, any previous MTRR region with offending size will block correct MTRR setup.

[Greg King (greg-james-king)]

That could be a fix. However it appears to be in regards to x86 (IA32) - although, this fix might work for 64 bit architectures.

 Further, its a little troubling that the last comments on this bug are from 2005-05 (I would expect that this code would have been rolled into the xserver code base).

[Fred Flegel (spen-launchlinux)]

I have the same problem here,
MSI P35 Mainboard, dualcore, radeon hd3650, 4gb ram.

I found fix in the forums: http://ubuntuforums.org/showthread.php?t=764214&goto=nextoldest

btw. this a not so new problem and shouldnt bugs causing hard locks be fixed faster?

[Greg King (greg-james-king)]

The only issue is that the hard lock actually has something to do with a closed source package (i.e. fglrx has an issue with the mtrr table, but the mtrr table is actually handled by the BIOS and kernel - then this problem lies with our ability to get information out of the fglrx binary driver). Further, since the binary drivers don't have debug symbols in them, we don't get a core dump out (it would be nice if I could send this information on to AMD/ATI to allow them a chance to fix the driver - provided its a bug in their code).

[Allan Nordhøy (comradekingu)]

Output of cat /proc/mtrr

X48 4GB 32bit ubuntu 8.04.1 3870

reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg03: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg04: base=0x130000000 (4864MB), size= 256MB: uncachable, count=1
reg05: base=0xcff00000 (3327MB), size= 1MB: uncachable, count=1

X48 3GB 64bit ubuntu 8.04.1 3870

reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg01: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg02: base=0xbff00000 (3071MB), size= 1MB: uncachable, count=1

[Andrew Case (darkfrog13)]

I also had the same problem with a Dell Optiplex 755 with a Radeon HD 2400 Pro when using 4gb of memory on an amd64 (x86_64) install of RHEL5.2. Disabling mtrr in the xorg.conf and disabling redhat's graphical boot seemed to do the trick. I'd like the pretty graphics on boot so users aren't exposed to that, but I can live without it. So my changes in sudo diff format:

/etc/sysconfig/init:
- GRAPHICAL=yes
+ GRAPHICAL=no

/etc/X11/xorg.conf:
Section "Device"
- Option "mtrr" "off" # This would use fglrx's own mtrr mapper code
+ Option "mtrr" "on" # Instead let the system handle it
    Option "no_accel" "no" # but keep accelleration
    Option "no_dri" "no" #and dri
EndSection

[Hinterland (zlorenzini)]

Just thought I would add my $0.02 because I have a Foxconn X38A board with a C2Q 6600 and 4GB of RAM. I also have a Sapphire ATI 3870 card. When I did a fresh install of Ubuntu 8.04, everything came up fine (and very fast), then I enabled the fglrx driver and when the system came back up, it went to a blank screen and nothing had any effect. I tried rebooting using the Reset button a couple of times and there was one situation where the computer did a spontaneous reboot after the splash screen, but mostly it would just sit there blank. And it was a powered blank, i.e. it was clear that the LCD backlight was on and the power light was green (no powersave).

After reading this article, I went into the BIOS and disabled the memory mapper and when I rebooted, the system came right up. If there are any commands I can issue to collect data to help with this bug, please let me know and I can turn my memory mapper back on, make it crash and provide information, if it would help this whole situation somehow.

[D. Hugh Redelmeier (hugh-mimosa)]

I'm trying to write a program to rejig MTRR settings to avoid this problem. More details to follow if it works.

It would help me if people would post the contents of /proc/mtrr for their systems. If you have a BIOS setting that avoids the problem, please post /proc/mtrr for both. It would also be good if you could tell us the address range that the video card is using.

Thanks.

[D. Hugh Redelmeier (hugh-mimosa)]

I've written the program. It works on my one system. Who knows if it works anywhere else.

Fetch it from ftp://ftp.cs.utoronto.ca/pub/hugh/mtrr-uncover-2008sept18.tgz

Untar it. cd into the new directory. Type "make". Read the manpage "man ./ mtrr-uncover.8"

Run the command (just a test!) "./mtrr-uncover". You should be able to see how the MTRRs are set up more clearly that /proc/mtrr shows it. You will also see the proposed revised version and the lines to be written to /proc/mtrr to effect that change.

For example, for the /proc/mtrr settings shown in the first message above, with remapping (the hard case), here is what my program shows. The entries are sorted by address. Inner nested values are indented to make this clear. Please give me feedback and do post /proc/mtrr for problematic systems.

Initial MTRR configuration:
 2 0x000000000-0x0ffffffff write-back
    0 0x0d0000000-0x0dfffffff uncachable
    1 0x0e0000000-0x0ffffffff uncachable
 3 0x100000000-0x11fffffff write-back
 4 0x120000000-0x12fffffff write-back

Final MTRR configuration:
 2' 0x000000000-0x07fffffff write-back
50' 0x080000000-0x0bfffffff write-back
51' 0x0c0000000-0x0cfffffff write-back
 3 0x100000000-0x11fffffff write-back
 4 0x120000000-0x12fffffff write-back

Commands for /proc/mtrr to make these changes:
disable=0
disable=1
disable=2
base=0x000000000 size=0x080000000 type=write-back
base=0x080000000 size=0x040000000 type=write-back
base=0x0c0000000 size=0x010000000 type=write-back

[denisius.sion (denisius-sion)]

still doesn't work

I have this messages:
[ 14.792019] uvesafb: NVIDIA Corporation, G86 Board - e416h01 , Chip Rev , OEM: NVIDIA, VBE v3.0
[ 15.034609] uvesafb: VBIOS/hardware doesn't support DDC transfers
[ 15.034722] uvesafb: no monitor limits have been set, default refresh rate will be used
[ 15.036169] uvesafb: scrolling: redraw
[ 15.036511] mtrr: type mismatch for fb000000,800000 old: write-back new: write-combining
[ 15.036682] mtrr: type mismatch for fb000000,400000 old: write-back new: write-combining
[ 15.036853] mtrr: type mismatch for fb000000,200000 old: write-back new: write-combining
[ 15.037031] mtrr: type mismatch for fb000000,100000 old: write-back new: write-combining
[ 15.037201] mtrr: type mismatch for fb000000,80000 old: write-back new: write-combining
[ 15.037374] mtrr: type mismatch for fb000000,40000 old: write-back new: write-combining
[ 15.037557] mtrr: type mismatch for fb000000,20000 old: write-back new: write-combining
[ 15.037728] mtrr: type mismatch for fb000000,10000 old: write-back new: write-combining
[ 15.037898] mtrr: type mismatch for fb000000,8000 old: write-back new: write-combining
[ 15.038076] mtrr: type mismatch for fb000000,4000 old: write-back new: write-combining
[ 15.038245] mtrr: type mismatch for fb000000,2000 old: write-back new: write-combining
[ 15.038436] mtrr: type mismatch for fb000000,1000 old: write-back new: write-combining
[ 15.038709] uvesafb: framebuffer at 0xfb000000, mapped to 0xffffc20010180000, using 13781k, total 14336k
[ 15.038893] fb0: VESA VGA frame buffer device

[denisius.sion (denisius-sion)]

and also I have in /proc/mtrr:

reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1

[Rich Hewitt (rich-e-hewitt)]

I just upgraded to Ubuntu 8.10 and I no longer need my manual MTRR fix in /etc/rc.local ... everything is fine using the default config.

[Greg King (greg-james-king)]

I've also checked with Ubuntu 8.10 - release candidate. It now handles memory remapping. In case people are wondering, my new mtrr tables:
gking@bender:~$ cat /proc/mtrr
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 256MB: write-back, count=1

[Fred Flegel (spen-launchlinux)]

Same here, using 8.10 rc with intel p35 chipset, 4gb ram and fglrx driver,
everything works!

ben@guarana:~$ cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg01: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg02: base=0x120000000 (4608MB), size= 256MB: write-back, count=1
reg04: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1

Thank you!

[Greg King (greg-james-king)]

Ubuntu 8.10-rc fglrx works with 4GB and memory remapping enabled.

[spontex (spontex)]

Hello,
Does this only apply to the 64-bits version, or is this also possible to get full advantage of 4GB under the 32-bits version?

Thanks

[Greg King (greg-james-king)]

I believe to get access to all 4GB of memory in 32 bit version requires the use of PAE or a BIGMEM kernel. To get access to all the memory in 32 bit version you would have to enable memory-remapping. I know that this bug will not affect someone using the stock kernel (but unsure of the bigmem or pae enabled kernel).

[D. Hugh Redelmeier (hugh-mimosa)]

With regard to my earlier comment ( https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/224404/comments/42 ):
I have updated the mtrr-uncover a few times. Look for the newest appropriately named tarball in the ftp directory: ftp://ftp.cs.utoronto.ca/pub/hugh/

[ilna (a-gaydenko)]

For D. Hugh Redelmeier:

I have tried to build mtrr-uncover-2009may13.tgz and got:

$ make
cc -Wall -g mtrr-uncover.c -o mtrr-uncover
mtrr-uncover.c:123: error: ‘mtrr_type’ redeclared as different kind of symbol
/usr/include/asm/mtrr.h:70: note: previous declaration of ‘mtrr_type’ was here
make: *** [mtrr-uncover] Error 1
//----------------------------------------

For All:

I have the same problem with up to date Kubuntu Karmic. Must I report a new bug?

[D. Hugh Redelmeier (hugh-mimosa)]

ilna: I notice that error now on my Fedora 11. I'm too lazy to check, but it looks as if the kernel header changed and hijacked a symbol that I had been using.

quick fix: issue this shell command in the mtrr directory
  sed -i -e 's/\<mtrr_type\>/&_dhr/g' mtrr-uncover.c

Then "make" again.

I am a bit surprised that you have MTRR problems when you are using a new kernel. I would have thought that the kernel's code to "clean up" MTRRs would be working. This code was added to the official kernel last year.

I would like to know more.

If you do report it as a new bug (and I don't know if you should report a new bug or add to this report), please do add a comment here telling us where to find the new report.

[ilna (a-gaydenko)]

For D. Hugh Redelmeier: thanks for fix! In fact I have resolved the issue with 'enable_mtrr_cleanup' boot option:

sudo cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x100000000 ( 4096MB), size= 2048MB, count=1: write-back
reg02: base=0x17c000000 ( 6080MB), size= 64MB, count=1: uncachable
reg03: base=0x0d0000000 ( 3328MB), size= 256MB, count=1: write-combining

[D. Hugh Redelmeier (hugh-mimosa)]

ilna:

Glad to hear that the kernel's clean up code worked. Could you post the /proc/mtrr contents when cleanup is not enabled? I'd like to see what it is fixing.

[D. Hugh Redelmeier (hugh-mimosa)]

This version of mtrr-uncover should compile cleanly with the new <asm/mtrr.h> header file.
  ftp://ftp.cs.utoronto.ca/pub/hugh/mtrr-uncover-2009august14.tgz

Thanks, ilna, for pointing out the problem.

[ilna (a-gaydenko)]

For D. Hugh Redelmeier: It's here:
http://ubuntuforums.org/showpost.php?p=7774450&postcount=1048