You are not logged in.
Pages: 1
It seems my laptop (an Acer Aspire One AOA150) runs out of MTRRs at boot. I've done some googling on the problem and read that people recommend turning on MTRR sanitizing to fix it, however, it still occurs. This occurs both with -ARCH and my own kernel config.
You can see that I have enabled MTRR sanitization here:
[chris@helios ~]$ zcat /proc/config.gz | fgrep 'SANITIZER'
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
Here is my system info (more than you'll need, just my standard printout):
http://pastie.org/private/eqatevtzhhwfwwxrzkxq
Thanks in advance for any help
Last edited by neurolysis (2011-04-01 13:43:33)
Offline
From the dmesg, it is easy to see that it runs out of mtrr during i915/drm graphics initialization. I have no specific experience with this problem, but here's my suggestions:
1. Boot with mtrr_spare_reg_nr=2 and you may also need enable_mtrr_cleanup=1 (add to kernel line in /boot/grub/menu.lst).
2. Try kernel 2.6.38 from [testing].
http://www.mjmwired.net/kernel/Document … s.txt#1529
http://fixunix.com/kernel/388642-patch- … out-4.html
Offline
But the thing is, mtrr is not relevant for graphics, because they use pat anyway. That line is only relevant for machines without pat (or if you boot with nopat on the kernel commandline).
Offline
From the dmesg, it is easy to see that it runs out of mtrr during i915/drm graphics initialization. I have no specific experience with this problem, but here's my suggestions:
1. Boot with mtrr_spare_reg_nr=2 and you may also need enable_mtrr_cleanup=1 (add to kernel line in /boot/grub/menu.lst).
2. Try kernel 2.6.38 from [testing].http://www.mjmwired.net/kernel/Document … s.txt#1529
http://fixunix.com/kernel/388642-patch- … out-4.html
No luck with either (I already had enable_mtrr_cleanup=1, which just changes CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT, but booting with mtrr_spare_reg_nr=2 doesn't fix it either). The error from drm has now disappeared, but this still remains:
[ 0.329894] mtrr: no more MTRRs available
But the thing is, mtrr is not relevant for graphics, because they use pat anyway. That line is only relevant for machines without pat (or if you boot with nopat on the kernel commandline).
Is there a good way to test this? Does the pat flag in /proc/cpuinfo indicate that MTRRs will not be used?
Last edited by neurolysis (2011-04-04 19:25:07)
Offline
Yes, there's a good way to test - boot with nopat on the kernel commandline, and you'll see crappy graphics performance.
Offline
Yes, there's a good way to test - boot with nopat on the kernel commandline, and you'll see crappy graphics performance.
I just booted with nopat... I get exactly the same performance. I'm guessing this means I use MTRRs?
A quick check also verifies nopat got acted on correctly:
[chris@helios ~]$ dmesg | grep -E 'PAT .* disabled'
[ 0.000000] PAT support disabled.
Last edited by neurolysis (2011-04-06 04:16:58)
Offline
When I booted with nopat, moving windows around caused heavy CPU usage, scrolling in Firefox was terrible, etc, etc.
So I have to ask... do you see any actual problems with your machine? You have to know, the gma950 is quite crap. It doesn't have hardware vertex shaders and even pixel shader performance is quite terrible. So anything that even remotely uses shaders, forget about it.
Last edited by Gusar (2011-04-06 09:52:43)
Offline
I don't get the same effects. I see no measurable difference in CPU usage when scrolling on a busy page (YouTube video) or moving windows between when I have PAT disabled or enabled.
Offline
Difference in CPU usage compared to what? Scrolling a page, especially one with the crap that is flash, will be CPU intensive on any machine. But do you notice lag in scrolling, or is it instantaneous? If there's no lag, everything is fine.
Offline
Difference in CPU usage compared to what? Scrolling a page, especially one with the crap that is flash, will be CPU intensive on any machine. But do you notice lag in scrolling, or is it instantaneous? If there's no lag, everything is fine.
There is lag in both cases. I have, however, just had it pointed out to me that I can rewrite /proc/mtrr, so I have done the following and put it in rc.local:
echo "disable=7" > /proc/mtrr
echo "disable=6" > /proc/mtrr
echo "disable=5" > /proc/mtrr
echo "disable=4" > /proc/mtrr
echo "disable=3" > /proc/mtrr
echo "disable=2" > /proc/mtrr
echo "disable=1" > /proc/mtrr
echo "disable=0" > /proc/mtrr
echo "base=0x000000000 size=0x40000000 type=write-back" > /proc/mtrr
echo "base=0x03f500000 size=0x00100000 type=uncachable" > /proc/mtrr
echo "base=0x03f600000 size=0x00200000 type=uncachable" > /proc/mtrr
echo "base=0x03f800000 size=0x00800000 type=write-back" > /proc/mtrr
echo "base=0x040000000 size=0x10000000 type=write-combining" > /proc/mtrr
Which seems to have helped (and I believe those are the right sizes and locations for each mtrr allocation).
Last edited by neurolysis (2011-04-06 13:10:46)
Offline
Pages: 1