Mailinglist Archive: radeonhd (312 mails)

< Previous Next >
Re: [radeonhd] 0x95C4:0x1734:0x113F: RADEON HD 3450 - ADDENDUM
  • From: Urigeller <Urigeller@xxxxxx>
  • Date: Fri, 24 Apr 2009 18:57:02 +0200
  • Message-id: <49F1EF5E.7070108@xxxxxx>
Matthias Hopf schrieb:
On Apr 24, 09 16:32:16 +0200, Urigeller wrote:
Matthias Hopf schrieb:
On Apr 24, 09 13:29:13 +0200, Marco De Lellis wrote:
The problem is related to the MTRR layout. I just take apart 1 GiB of RAM
and radeonhd started flawlessly. So I'm investigating further the MTRR
I assume you had 4GB of RAM in your system?
This issue urgently needs fixing - unfortunately we didn't really have a
clue so far or not enough time to actually dig into it. It mostly
happened on laptops so far.
If this is the issue I think it is, I believe the problem is not going
to be found within the graphics driver.

Doesn't matter. Any solution would be fine.

There are some weird memory layout errors that arise with BIOS on Intel
chipsets with 4 GB oder more RAM installed. If I boot my system without
a manually added MTRR hack to the boot process I'm not able to start any
kind of graphical environment. A 'cat /proc/mtrr' should tell if your
issue is the one I'm talking about. A quick search gave me this,
although I didn't read the whole thread, the first post describes the

I do not exactly read from this post what I would have to do in order to
start the system correctly. Or is this impossible at this point?



One way to fix this problem is reducing the amount of RAM below 4GB (-;
Alternatively one can disable memory remapping (above the 32bit address
space limit) in the BIOS, if this option is present (which of course has
the same effect as physically removing RAM).
Obviously neither of these options is that great so the approach I took
after I encountered this problem around a year ago was to "simply"
rewrite my MTRR at booting time. For comparison, this is what "cat
/proc/mtrr" looked like with memory remapping enabled on a system with
4GB of RAM:

# original state (remapping enabled):
# 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

After I spent quite some time googling around I stumbled across a post
in the Phoronix forae which basically told me how to first delete all
the register ranges and then write new ones with better values. Note
however that the following is likely to depend on my chipset, BIOS and

for number in 2 1 3 4 0 # order is important!
echo "disable=$number" >| /proc/mtrr

This snippet (bash) just disables all my mtrr. After that I'm using the
following code to create more reasonable ranges:

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=0x100000000 size=0x20000000 type=write-back" >| /proc/mtrr
echo "base=0x120000000 size=0x10000000 type=write-back" >| /proc/mtrr

It should be noted however, that I'm far from being an expert in memory
type range registers and that these values are dependant on my
configuration. But they provide me with a bootable, working operating
system without the need to modify my hardware. I found this solution
after searching around for some time it's not based on any in-depth
expertise or understanting of the subject. I believe one could look at
the BIOS provided memory map at the beginning of dmesg for hints.

On an additional note, recent kernels (not sure which one) introduced
CONFIG_MTRR_SANITIZER, but I believe it didn't solve my problem. I'm not
sure about the latter since I have disabled it in my current kernel
config and the MTRR hack is working well since about a year now.

I know of some other people who also took this hacking approach but it
should be said that this is probably far from being a good solution for
the problem. On the other hand it's difficult to find a person with
knowledge about these things and even Intel seems not to be able to get
this right, at least I'm not aware of it.
Also there is a successor technique named PAT (Page Attribute Tables)
that is supported in recent kernels (again not sure since when), but as
I said.. I'm not an expert in these things (although I whish I was).

To unsubscribe, e-mail: radeonhd+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: radeonhd+help@xxxxxxxxxxxx

< Previous Next >