0x95C4:0x1734:0x113F: RADEON HD 3450 - ADDENDUM
Hello, I kind of solved the problem I noticed yesterday. 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 thing. Thanks anyway. Marco De Lellis -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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 thing.
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.
I you find anything conclusive, that would be very helpful.
Matthias
--
Matthias Hopf
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 thing.
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.
I you find anything conclusive, that would be very helpful.
Matthias
If this is the issue I think it is, I believe the problem is not going to be found within the graphics driver. 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 problem: http://lkml.org/lkml/2007/6/1/231 Uri -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
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 thing.
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 problem: http://lkml.org/lkml/2007/6/1/231
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?
Thanks
Matthias
--
Matthias Hopf
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 thing. 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 problem: http://lkml.org/lkml/2007/6/1/231
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?
Thanks
Matthias
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 whatnot. for number in 2 1 3 4 0 # order is important! do echo "disable=$number" >| /proc/mtrr done 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). regards, Uri -- To unsubscribe, e-mail: radeonhd+unsubscribe@opensuse.org For additional commands, e-mail: radeonhd+help@opensuse.org
participants (3)
-
Marco De Lellis
-
Matthias Hopf
-
Urigeller