Christoph Piefke wrote:
Matthias Hopf wrote:
On May 06, 09 10:34:53 +0200, Christoph Piefke wrote:
Does removing one of the ram chips in your system help?
Yes, it works fine, except that this procedure creates a rather useless paperweight worth of 2GB ram. But screen resolution is just fine.
Xorg.0.log can be found here: http://pastebin.com/m4c03dfd6
You might have some luck with this description:
http://lists.opensuse.org/radeonhd/2009-04/msg00253.html
Given the complexity of the issue, you're pretty much on your own right now, until somebody who *really* understands the issue (which is, for instance, not me) sits down and creates a great mtrr workaround patch for the kernel :-(
Matthias
I think I can update some of the informations on the issue which I described in the post that Matthias linked to. I recently chose to look again at the mentioned kernel option CONFIG_MTRR_SANITIZER. It's located in the "Processor type and features" section, down at the option for MTRR support.
I enabled MTRR cleanup support (CONFIG_MTRR_SANITIZER), set MTRR cleanup enable value (CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT) to 1 and set MTRR cleanup spare reg num (CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT) to 0. After that, my dmesg looks like this (excerpt):
[ 0.000000] original variable MTRRs
[ 0.000000] reg 0, base: 3328MB, range: 256MB, type UC
[ 0.000000] reg 1, base: 3584MB, range: 512MB, type UC
[ 0.000000] reg 2, base: 0GB, range: 4GB, type WB
[ 0.000000] reg 3, base: 4GB, range: 512MB, type WB
[ 0.000000] reg 4, base: 4608MB, range: 256MB, type WB
[ 0.000000] total RAM coverred: 4096M
[ 0.000000] Found optimal setting for mtrr clean up
[ 0.000000] gran_size: 64K chunk_size: 64K num_reg: 5 lose cover RAM: 0G [ 0.000000] New variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 2GB, type WB
[ 0.000000] reg 1, base: 2GB, range: 1GB, type WB
[ 0.000000] reg 2, base: 3GB, range: 256MB, type WB
[ 0.000000] reg 3, base: 4GB, range: 512MB, type WB
[ 0.000000] reg 4, base: 4608MB, range: 256MB, type WB
This corresponds to the values in my original post. So I disabled my little hack and I'm having no problems so far (running this configuration since about a month). This workaround inside the kernel is probably much better than mine because it corrects the MTRRs as one of its first actions. I had to rely on a boot script (which of course kicks in much later) to do this cleanup.
Also, this probably implicates that the kernel has a viable method to detect and corret erroneous MTRR tables without any further user action. If you want to take a shot at this I recommend to read the help pages of the mentioned kernel options, this behaviour can be modified through boot parameters (to save you reboots and reconfigurations of your kernel).
regards, Uri -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Well, this sound really promising! I will try this, but I am a little bit lost here. Are these flags boot options or are they compiler flags and I have to rebuild my kernel? Where do I find the help pages for the mentioned kernel options?
regards, Chris
Looking at Documentation/kernel-parameters.txt of 2.6.27.10 (gentoo), Uri's configuration can be accomplished with these parameters when MTRR cleanup support is enabled: "enable_mtrr_cleanup mtrr_spare_reg_nr=0" -- Chris -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org