HD 3650/ fglrx wants 4GB of VideoRAM/ radeonhd v 1.2.5 crashes
Good morning radeonhd mailinglist, bridgman from the phoronix.com forum suggest that I present my interesting new bug here to the mailinglist. I am on a Toshiba Satellite A350-12D/ Kubuntu 9.04 machine with a VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3650. When I use the latest fglrx or Catalyst driver (9.4), X starts, but I get a blank screen. Xorg.0.log gives me messages like: (EE) fglrx(0): Unknown EDID version 0 (II) fglrx(0): Display1: Failed to get EDID information. (II) fglrx(0): Connected Display2: TV on TVDAC [tv] (II) fglrx(0): Display2: No EDID information from DDC. (EE) fglrx(0): Unknown EDID version 0 (EE) fglrx(0): [pcie] Failed to gather memory of size 0Kb for PCIe. Error (-1) (--) fglrx(0): Video RAM: 4194303 kByte, Type: DDR2 (II) fglrx(0): [FB] MC range(MCFBBase = 0x0, MCFBSize = 0x100000000) (II) fglrx(0): PCIE card detected (--) fglrx(0): Using per-process page tables (PPPT) as GART. (WW) fglrx(0): board is an unknown third party board, chipset is supported or (II) RADEON(0): Detected total video RAM=4194303K, accessible=524288K (PCI BAR=524288K) The entire thread can be found here, http://www.phoronix.com/forums/showthread.php?t=16691, including the Xorg.0.log-files and some speculations about RAM missmanagement. Since I am using "vesa"-mode with a terribly wrong resolution on my screen, I gave version 1.2.5 of the radeonhd driver via git a chance. That gave very interesting results: (EE) RADEONHD(0): rhdAtomLvdsDDC: unknown record type: b8 (EE) RADEONHD(0): D1CRTCDisable: Failed to Unsync CRTC 1 (EE) RADEONHD(0): rhdAllIdle: unable to stop CRTC: cannot idle MC Fatal server error: AddScreen/ScreenInit failed for driver 0 Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information. ddxSigGiveUp: Closing log The entire Xorg.0.log can be found here: http://pastebin.com/m703fdffd The thread on phoronix is http://www.phoronix.com/forums/showthread.php?t=16820 Thank you for your time, Christoph -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On Tue, May 5, 2009 at 2:04 AM,
Good morning radeonhd mailinglist,
bridgman from the phoronix.com forum suggest that I present my interesting new bug here to the mailinglist.
I am on a Toshiba Satellite A350-12D/ Kubuntu 9.04 machine with a VGA compatible controller: ATI Technologies Inc Mobility Radeon HD 3650.
When I use the latest fglrx or Catalyst driver (9.4), X starts, but I get a blank screen. Xorg.0.log gives me messages like:
(EE) fglrx(0): Unknown EDID version 0 (II) fglrx(0): Display1: Failed to get EDID information. (II) fglrx(0): Connected Display2: TV on TVDAC [tv] (II) fglrx(0): Display2: No EDID information from DDC. (EE) fglrx(0): Unknown EDID version 0
(EE) fglrx(0): [pcie] Failed to gather memory of size 0Kb for PCIe. Error (-1)
(--) fglrx(0): Video RAM: 4194303 kByte, Type: DDR2 (II) fglrx(0): [FB] MC range(MCFBBase = 0x0, MCFBSize = 0x100000000) (II) fglrx(0): PCIE card detected (--) fglrx(0): Using per-process page tables (PPPT) as GART. (WW) fglrx(0): board is an unknown third party board, chipset is supported
or
(II) RADEON(0): Detected total video RAM=4194303K, accessible=524288K (PCI BAR=524288K)
The entire thread can be found here, http://www.phoronix.com/forums/showthread.php?t=16691, including the Xorg.0.log-files and some speculations about RAM missmanagement.
Since I am using "vesa"-mode with a terribly wrong resolution on my screen, I gave version 1.2.5 of the radeonhd driver via git a chance. That gave very interesting results:
(EE) RADEONHD(0): rhdAtomLvdsDDC: unknown record type: b8 (EE) RADEONHD(0): D1CRTCDisable: Failed to Unsync CRTC 1 (EE) RADEONHD(0): rhdAllIdle: unable to stop CRTC: cannot idle MC
Fatal server error: AddScreen/ScreenInit failed for driver 0
Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at "/var/log/Xorg.0.log" for additional information.
ddxSigGiveUp: Closing log
The entire Xorg.0.log can be found here: http://pastebin.com/m703fdffd The thread on phoronix is http://www.phoronix.com/forums/showthread.php?t=16820
Does removing one of the ram chips in your system help? Alex -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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 Chris -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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
--
Matthias Hopf
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
----- Original Message ----- From: Urigeller@gmx.de To: radeonhd@opensuse.org Date: 06.05.2009 13:15:11 Subject: Re: [radeonhd] HD 3650/ fglrx wants 4GB of VideoRAM/ radeonhd v 1.2.5 crashes
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 -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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
Christoph Piefke wrote:
----- Original Message ----- From: Urigeller@gmx.de To: radeonhd@opensuse.org Date: 06.05.2009 13:15:11 Subject: Re: [radeonhd] HD 3650/ fglrx wants 4GB of VideoRAM/ radeonhd v 1.2.5 crashes
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
I'm sorry for the confusion. This options can be used either via boot parameters or via kernel options at configuration time. Both methods need CONFIG_MTRR_SANITIZER=y I don't know which one takes precedence when both are used (built-in values and boot parameters). regards, Uri -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/5/6 Christoph Piefke
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?
Your kernel may already have that options enabled: grep "CONFIG_MTRR" /boot/config* -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
On May 06, 09 19:58:59 +0200, Rafał Miłecki wrote:
2009/5/6 Christoph Piefke
: 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? Your kernel may already have that options enabled: grep "CONFIG_MTRR" /boot/config*
Many, many thanks for analyzing this, Uri. Thanks for the support,
Chris, Rafal!
I have documented this now in the Wiki. Let's hope this issue is moot now.
Matthias
--
Matthias Hopf
Bad news everyone, it does not work. I changed the boot flags as Uri suggested, but the problem is not solved. In fact, it does not affect my /proc/mtrr: off: reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back reg03: base=0x0ffe00000 ( 4094MB), size= 512KB, count=1: write-protect on: reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back reg03: base=0x0ffe00000 ( 4094MB), size= 512KB, count=1: write-protect You can find the Xorg.o.log - files for the 2GB and 4GB installed case here: 2GB: http://pastebin.com/m3a8035ce 4GB: http://pastebin.com/m49c26eac regards, Chris ----- Original Message ----- From: mhopf@suse.de To: zajec5@gmail.com Date: 07.05.2009 11:54:16 Subject: Re: [radeonhd] HD 3650/ fglrx wants 4GB of VideoRAM/ radeonhd v 1.2.5 crashes
On May 06, 09 19:58:59 +0200, RafaÅ MiÅecki wrote:
2009/5/6 Christoph Piefke :
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? Your kernel may already have that options enabled: grep "CONFIG_MTRR" /boot/config*
Many, many thanks for analyzing this, Uri. Thanks for the support, Chris, Rafal! I have documented this now in the Wiki. Let's hope this issue is moot now.
Matthias
-- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
----- Original Message ----- From: mhopf@suse.de To: zajec5@gmail.com Date: 07.05.2009 11:54:16 Subject: Re: [radeonhd] HD 3650/ fglrx wants 4GB of VideoRAM/ radeonhd v 1.2.5 crashes
On May 06, 09 19:58:59 +0200, RafaÅ MiÅecki wrote:
2009/5/6 Christoph Piefke :
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? Your kernel may already have that options enabled: grep "CONFIG_MTRR" /boot/config*
Many, many thanks for analyzing this, Uri. Thanks for the support, Chris, Rafal! I have documented this now in the Wiki. Let's hope this issue is moot now.
Matthias
-- Matthias Hopf __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/5/14 Christoph Piefke
Bad news everyone,
it does not work. I changed the boot flags as Uri suggested, but the problem is not solved. In fact, it does not affect my /proc/mtrr:
off: reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back reg03: base=0x0ffe00000 ( 4094MB), size= 512KB, count=1: write-protect
on: reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back reg03: base=0x0ffe00000 ( 4094MB), size= 512KB, count=1: write-protect
You can find the Xorg.o.log - files for the 2GB and 4GB installed case here:
Correct me if I'm wrong but you have to use kernel compiled with CONFIG_MTRR_SANITIZER enabled. Please give us your output of two commands: uname -a grep "CONFIG_MTRR" /boot/config* -- Rafał Miłecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Here you are: sputnik:~$ uname -a Linux sputnik 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux sputnik:~$ grep "CONFIG_MTRR" /boot/config* /boot/config-2.6.28-11-generic:CONFIG_MTRR=y /boot/config-2.6.28-11-generic:CONFIG_MTRR_SANITIZER=y /boot/config-2.6.28-11-generic:CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 /boot/config-2.6.28-11-generic:CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 regards, Chris ----- Original Message ----- From: zajec5@gmail.com To: anmeldung@dunklevollnuss.de Date: 14.05.2009 08:30:40 Subject: Re: Re: [radeonhd] HD 3650/ fglrx wants 4GB of VideoRAM/ radeonhd v 1.2.5 crashes
2009/5/14 Christoph Piefke :
Bad news everyone,
it does not work. I changed the boot flags as Uri suggested, but the problem is not solved. In fact, it does not affect my /proc/mtrr:
off: reg00: base=0x000000000 ( Â Â 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back reg03: base=0x0ffe00000 ( 4094MB), size= Â 512KB, count=1: write-protect
on: reg00: base=0x000000000 ( Â Â 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back reg03: base=0x0ffe00000 ( 4094MB), size= Â 512KB, count=1: write-protect
You can find the Xorg.o.log - files for the 2GB and 4GB installed case here:
Correct me if I'm wrong but you have to use kernel compiled with CONFIG_MTRR_SANITIZER enabled.
Please give us your output of two commands: uname -a grep "CONFIG_MTRR" /boot/config*
-- RafaÅ MiÅecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Christoph Piefke wrote:
Here you are:
sputnik:~$ uname -a Linux sputnik 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux
sputnik:~$ grep "CONFIG_MTRR" /boot/config* /boot/config-2.6.28-11-generic:CONFIG_MTRR=y /boot/config-2.6.28-11-generic:CONFIG_MTRR_SANITIZER=y /boot/config-2.6.28-11-generic:CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 /boot/config-2.6.28-11-generic:CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
regards, Chris
----- Original Message ----- From: zajec5@gmail.com To: anmeldung@dunklevollnuss.de Date: 14.05.2009 08:30:40 Subject: Re: Re: [radeonhd] HD 3650/ fglrx wants 4GB of VideoRAM/ radeonhd v 1.2.5 crashes
2009/5/14 Christoph Piefke :
Bad news everyone,
it does not work. I changed the boot flags as Uri suggested, but the problem is not solved. In fact, it does not affect my /proc/mtrr:
off: reg00: base=0x000000000 ( Â Â 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back reg03: base=0x0ffe00000 ( 4094MB), size= Â 512KB, count=1: write-protect
on: reg00: base=0x000000000 ( Â Â 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back reg03: base=0x0ffe00000 ( 4094MB), size= Â 512KB, count=1: write-protect
You can find the Xorg.o.log - files for the 2GB and 4GB installed case here: Correct me if I'm wrong but you have to use kernel compiled with CONFIG_MTRR_SANITIZER enabled.
Please give us your output of two commands: uname -a grep "CONFIG_MTRR" /boot/config*
-- Rafa� Mi�ecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Chris, please post the entire boot line from your bootmanager, i.e. please tell us exactly which boot options you're using. Thanks. regards, Uri -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
For completeness (I am not enterly sure what you want to see): /boot/grub/menu.lst: http://pastebin.com/m17433f1b /boot/config-blabla: http://pastebin.com/m71342325 regards, Chris ----- Original Message ----- From: Urigeller@gmx.de To: radeonhd@opensuse.org Date: 14.05.2009 14:40:55 Subject: Re: [radeonhd] HD 3650/ fglrx wants 4GB of VideoRAM/ radeonhd v 1.2.5 crashes
Christoph Piefke wrote:
Here you are:
sputnik:~$ uname -a Linux sputnik 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux
sputnik:~$ grep "CONFIG_MTRR" /boot/config* /boot/config-2.6.28-11-generic:CONFIG_MTRR=y /boot/config-2.6.28-11-generic:CONFIG_MTRR_SANITIZER=y /boot/config-2.6.28-11-generic:CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0 /boot/config-2.6.28-11-generic:CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
regards, Chris
----- Original Message ----- From: zajec5@gmail.com To: anmeldung@dunklevollnuss.de Date: 14.05.2009 08:30:40 Subject: Re: Re: [radeonhd] HD 3650/ fglrx wants 4GB of VideoRAM/ radeonhd v 1.2.5 crashes
2009/5/14 Christoph Piefke :
Bad news everyone,
it does not work. I changed the boot flags as Uri suggested, but the problem is not solved. In fact, it does not affect my /proc/mtrr:
off: reg00: base=0x000000000 ( Ã Ã 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back reg03: base=0x0ffe00000 ( 4094MB), size= Ã 512KB, count=1: write-protect
on: reg00: base=0x000000000 ( Ã Ã 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back reg03: base=0x0ffe00000 ( 4094MB), size= Ã 512KB, count=1: write-protect
You can find the Xorg.o.log - files for the 2GB and 4GB installed case here: Correct me if I'm wrong but you have to use kernel compiled with CONFIG_MTRR_SANITIZER enabled.
Please give us your output of two commands: uname -a grep "CONFIG_MTRR" /boot/config*
-- Rafaà ᅵ Mià ᅵecki -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Chris,
please post the entire boot line from your bootmanager, i.e. please tell us exactly which boot options you're using. Thanks.
regards, Uri -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
2009/5/14 Christoph Piefke
For completeness (I am not enterly sure what you want to see):
/boot/grub/menu.lst: http://pastebin.com/m17433f1b
Not Found -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
What did you not find? The pastebin link is working fine here. ----- Original Message ----- From: zajec5@gmail.com To: anmeldung@dunklevollnuss.de Date: 14.05.2009 21:34:45 Subject: Re: Re: [radeonhd] HD 3650/ fglrx wants 4GB of VideoRAM/ radeonhd v 1.2.5 crashes
2009/5/14 Christoph Piefke :
For completeness (I am not enterly sure what you want to see):
/boot/grub/menu.lst: http://pastebin.com/m17433f1b
Not Found -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
-- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
Christoph Piefke wrote:
What did you not find? The pastebin link is working fine here.
----- Original Message ----- From: zajec5@gmail.com To: anmeldung@dunklevollnuss.de Date: 14.05.2009 21:34:45 Subject: Re: Re: [radeonhd] HD 3650/ fglrx wants 4GB of VideoRAM/ radeonhd v 1.2.5 crashes
2009/5/14 Christoph Piefke :
For completeness (I am not enterly sure what you want to see):
/boot/grub/menu.lst: http://pastebin.com/m17433f1b
The link works fine here. Take a look at the kernel (aka boot) lines (135/141 or 146/152). There are no options for the mtrr sanitizer specified. Just these: ro xforcevesa quiet splash ro xforcevesa single Please add the following options to the lines starting with "kernel": (see http://www.x.org/wiki/radeonhd#head-d2ffccb02dd625f846dd8197bad71ee38109b876 section 10.7) enable_mtrr_cleanup mtrr_spare_reg_nr=0 regards, Ur -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
The link works fine here. Take a look at the kernel (aka boot) lines (135/141 or 146/152). There are no options for the mtrr sanitizer specified. Just these:
ro xforcevesa quiet splash ro xforcevesa single
Please add the following options to the lines starting with "kernel": (see http://www.x.org/wiki/radeonhd#head-d2ffccb02dd625f846dd8197bad71ee38109b876 section 10.7)
enable_mtrr_cleanup mtrr_spare_reg_nr=0
I added the line to the list, my /proc/mtrr changed: reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back was: reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x100000000 ( 4096MB), size= 1024MB, count=1: write-back reg03: base=0x0ffe00000 ( 4094MB), size= 512KB, count=1: write-protect But it still does not work. Same errors as before, radeonhd just crashes. -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (7)
-
Alex Deucher
-
anmeldung@dunklevollnuss.de
-
Chris Bandy
-
Christoph Piefke
-
Matthias Hopf
-
Rafał Miłecki
-
Urigeller