[i915GM] MTRR entry gets removed when restarting xorg - causes corruption on ttys

[Sebastian Keller]

[Impact]
This bug is one of a set of fairly serious issues that afflict -intel users on Jaunty. The problem is that X and the kernel are miscommunicating about MTRR's, and X ends up deleting ones it shouldn't.

The user-visible effect of this is poor performance in video playback, such as very choppy flash video.

[Solution]
The solution for this issue is composed by a kernel patch and a xorg patch, both from the -intel upstream developers. Both of these patches are upstream, and currently included as of the 2.6.30 kernel and -intel 2.7.99.x in Karmic, which does not exhibit the bug. For Jaunty both of these need backported.

Kernel patch: http://people.ubuntu.com/~apw/lp314928-jaunty/0001-UBUNTU-SAUCE-drm-i915-Set-up-an-MTRR-covering-the-GT.patch

-intel patch:
  http://launchpadlibrarian.net/28453154/122_dont_fixup_mtrrs_in_gem_config.patch

The kernel patch sets the MTRR correctly and the Xorg patch assures that reloading xorg doesn't wipe it.

It's not necessary to roll out both patches simultaneously, but both linux and -intel need their patches in order to make the bug be resolved.

[Test Case]
0. Verify flash video playback is relatively okay
1. Note contents of /proc/mtrr
2. Restart xorg
3. Note contents of /proc/mtrr again, and how it has changed since #1
4. See that flash video playback is laggy

[Regression Potential]
Reasonably low. This change has been reviewed and tested upstream and in karmic for quite a while, and the specific patches being proposed in this SRU have been provided for testers via a PPA and verified to solve the bug. Due to the nature of the patch, it's not possible to prove definitively that it can't cause regression, so it would be advisable to test this thoroughly in jaunty-proposed.

[Original Report]
When comparing /proc/mtrr of intrepid and current jaunty i noticed there is an entry missing.

Intrepid:
reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
reg02: base=0x5f700000 (1527MB), size= 1MB: uncachable, count=1
reg03: base=0x5f800000 (1528MB), size= 8MB: uncachable, count=1
reg04: base=0xb0000000 (2816MB), size= 256MB: write-combining, count=1

Jaunty:
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x040000000 ( 1024MB), size= 512MB, count=1: write-back
reg02: base=0x05f700000 ( 1527MB), size= 1MB, count=1: uncachable
reg03: base=0x05f800000 ( 1528MB), size= 8MB, count=1: uncachable

So I tried adding it back by using:
sudo -s
echo "base=0xb0000000 size=0x10000000 type=write-combining" > /proc/mtrr

I have noticed a few things after adding that entry:
- glxgears is now about twice as fast (I know its not a real benchmark ;)
- 2D Performance does not seem affected however (just testing a bit with x11perf/gtkperf)
- it fixes the corruption on the ttys (bug 312677)

I also noticed that this entry gets removed everytime xorg gets restarted.

But I'm not sure with all the recent changes in memory management if that entry should still be there or not.

-------------

lspci
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03)
00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev d3)
00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
00:1e.3 Modem: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Modem Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation 82801FBM (ICH6M) LPC Interface Bridge (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801FBM (ICH6M) SATA Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) SMBus Controller (rev 03)
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751M Gigabit Ethernet PCI Express (rev 11)
04:00.0 CardBus bridge: Texas Instruments PCI4510 PC card Cardbus Controller (rev 03)
04:00.1 FireWire (IEEE 1394): Texas Instruments PCI4510 IEEE-1394 Controller (rev 01)
04:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)

[Bryce Harrington (bryce)]

[This is an automated message]

Hi skeller,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

Please attach the output of `lspci -vvnn` too.

[Conn O Griofa (psyke83)]

I can confirm this on a DELL Inspiron 510m laptop & Jaunty, with all the latest updates. The most notable problem I experience is stuttering video through Totem (using the standard GStreamer backend, Xv output) and other media players.

Relevant lspci -vvnn output:

00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)
 Subsystem: Dell Device [1028:0164]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
 Latency: 0
 Interrupt: pin A routed to IRQ 11
 Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
 Region 1: Memory at faf80000 (32-bit, non-prefetchable) [size=512K]
 Region 2: I/O ports at c000 [size=8]
 Capabilities: <access denied>
 Kernel modules: intelfb

Current MTRR setup:

conn@inspiron:~$ cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 512MB, count=1: write-back
reg01: base=0x020000000 ( 512MB), size= 256MB, count=1: write-back
reg02: base=0x02ff00000 ( 767MB), size= 1MB, count=1: uncachable
reg03: base=0x0feda0000 ( 4077MB), size= 128KB, count=1: write-through

The fix:
sudo -s
echo "base=0xF0000000 size=0x08000000 type=write-combining" >| /proc/mtrr

Enabling write combining allows Totem to play 720p content with absolutely no stuttering (compared to low-resolution content stuttering without the fix). I can't say that I notice a huge increase in 3D performance, however. I won't bother to report glxgears scores, it's not an accurate tool to measure performance.

[kuser (nuca-nunca)]

hello there,
i landed here after a long www odysee related to that new choppy flash in fullscreen issue in jaunty alpha.
onboard chip i915gm
typing this into terminal: cat /proc/mtrr
gives me those quite minimal info...
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x07f800000 ( 2040MB), size= 8MB, count=1: uncachable
so i got the super bug?
please tell me if more info needed.

[kuser (nuca-nunca)]

ok, the here proposed fix really helps, thank u so much, so what i did was this:
first checked for the region:
lspci -vvnn:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller [8086:2592] (rev 04)
        Subsystem: Uniwill Computer Corp Device [1584:9800]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at ffe80000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at ec00 [size=8]
        Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at ffe40000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: <access denied>
        Kernel modules: intelfb

then enabled it:
sudo -s
echo "base=0xd0000000 size=0x10000000 type=write-combining" > /proc/mtrr

[drag0njoe (drag0njoe)]

Thanks, fixed video playing/youtube problems on my Toshiba Tecra A8 (i945 GM).
Seems this problem affects many Intel GPU...

Detailed:
#lspci -vvnn
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
 Subsystem: Toshiba America Info Systems Device [1179:0005]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at ffd80000 (32-bit, non-prefetchable) [size=512K]
 Region 1: I/O ports at cff8 [size=8]
 Region 2: Memory at e0000000 (32-bit, prefetchable) [size=256M]
 Region 3: Memory at ffd40000 (32-bit, non-prefetchable) [size=256K]
 Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
  Address: 00000000 Data: 0000
 Capabilities: [d0] Power Management version 2
  Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel modules: intelfb

root@drag0njoe-laptop:~# cat /proc/mtrr
reg00: base=0x0feda0000 ( 4077MB), size= 128KB, count=1: write-back
reg01: base=0x07f800000 ( 2040MB), size= 8MB, count=1: uncachable
reg02: base=0x0fff00000 ( 4095MB), size= 1MB, count=1: write-protect
reg03: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
root@drag0njoe-laptop:~# echo "base=0xe0000000 size=0x10000000 type=write-combining" > /proc/mtrr
root@drag0njoe-laptop:~# cat /proc/mtrr
reg00: base=0x0feda0000 ( 4077MB), size= 128KB, count=1: write-back
reg01: base=0x07f800000 ( 2040MB), size= 8MB, count=1: uncachable
reg02: base=0x0fff00000 ( 4095MB), size= 1MB, count=1: write-protect
reg03: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg04: base=0x0e0000000 ( 3584MB), size= 256MB, count=1: write-combining

[Conn O Griofa (psyke83)]

Bryce & others,

It seems this issue is relevant to many (if not all?) Intel chipset users. I have access to three systems with integrated graphics - a 900GMA desktop, 865G desktop and 855GM laptop - and none of these systems setup write-combining MTRR ranges properly.

Although this causes issues mostly with video playback, it will only exacerbate complaints of slowness for Intel users in the Jaunty release. I suggest this bug is treated as a high priority and squished in a SRU as soon as possible.

Do you need any further logs or debug information to help?

[Jose Bernardo (bernardo-bandos)]

On my aspire one 110L running jaunty (freshly updated) this doesn't work:
# echo "base=0x60000000 size=0x10000000 type=write-combining" > /proc/mtrr
bash: echo: erro de escrita: Dispositivo sem espaço livre

(which is the translation for "write error:device full", I think)

lspci -vvnn:
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03)
        Subsystem: Acer Incorporated [ALI] Device [1025:015b]
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at 78480000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at 60c0 [size=8]
        Region 2: Memory at 60000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at 78500000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
                Address: 00000000 Data: 0000
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Kernel modules: intelfb

cat /proc/mtrr:
reg00: base=0x0fffe0000 ( 4095MB), size= 128KB, count=1: write-protect
reg01: base=0x0fffc0000 ( 4095MB), size= 128KB, count=1: uncachable
reg02: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg03: base=0x040000000 ( 1024MB), size= 512MB, count=1: write-back
reg04: base=0x05f800000 ( 1528MB), size= 8MB, count=1: uncachable
reg05: base=0x05f600000 ( 1526MB), size= 2MB, count=1: uncachable
reg06: base=0x05f500000 ( 1525MB), size= 1MB, count=1: uncachable
reg07: base=0x000000000 ( 0MB), size= 128KB, count=1: uncachable

and from Xorg.0.log:
(--) PCI:*(0@0:2:0) Intel Corporation Mobile 945GME Express Integrated Graphics Controller rev 3, Mem @ 0x78480000/524288, 0x60000000/268435456, 0x78500000/262144, I/O @ 0x000060c0/8
[...]
(II) intel(0): Integrated Graphics Chipset: Intel(R) 945GME
(--) intel(0): Chipset: "945GME"
(--) intel(0): Linear framebuffer at 0x60000000
(--) intel(0): IO registers at addr 0x78480000
(WW) intel(0): libpciaccess reported 0 rom size, guessing 64kB
(==) intel(0): Using EXA for acceleration

[incubusss (mdv)]

Created an attachment (id=24973)
Xorg log after

kernel 2.6.29.1, X server 1.6.1, intel driver 2.7.0, and EXA acceleration

At first X start, acceleration is normal. Then if X is restarted, I loose it (glxgears reports half the expected FPS, games are extremely slow).

Seems to be related to mtrr :

Before :
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f700000 ( 1015MB), size= 1MB, count=1: uncachable
reg02: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable
reg03: base=0x0c0000000 ( 3072MB), size= 256MB, count=1: write-combining

After :
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f700000 ( 1015MB), size= 1MB, count=1: uncachable
reg02: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable

After restarting, there is this error in xorg log:

(WW) intel(0): ESR is 0x00000001, instruction error
(WW) intel(0): Existing errors found in hardware state.

[incubusss (mdv)]

Created an attachment (id=24974)
Xorg log before restart

[Francois Rigaut (francois.rigaut)]

Thanks for the fix. Got the same problem with a GM945, and this seems to fix it.
I've read somewhere in this thread that the new line in /proc/mtrr gets wiped out after a reboot (or X restart?). Do any of you have any advice on how to implement this fix so that it survives reboots?
I mean, it's always possible to have it user side, but there might be a better solution.
Also, is that really OK to add this *after* X is started, or would it benefit from being done before X is started?

[sunken (sunken76)]

When you've found the line that works best for your system you could add it to /etc/rc.local

In my case:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
echo "base=0xe0000000 size=0x10000000 type=write-combining" > /proc/mtrr
exit 0

[sunken (sunken76)]

One thing to do is to add the echo line to /etc/rc.local

2009/4/20 Francois Rigaut <email address hidden>

> Thanks for the fix. Got the same problem with a GM945, and this seems to
> fix it.
> I've read somewhere in this thread that the new line in /proc/mtrr gets
> wiped out after a reboot (or X restart?). Do any of you have any advice on
> how to implement this fix so that it survives reboots?
> I mean, it's always possible to have it user side, but there might be a
> better solution.
> Also, is that really OK to add this *after* X is started, or would it
> benefit from being done before X is started?
>
> --
> [i915GM] MTRR entry missing since jaunty - is this intentional?
> https://bugs.launchpad.net/bugs/314928
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Francois Rigaut (francois.rigaut)]

@Sunkem. Thanks. But that only works for your first xorg session. If you kill the X server (or log out/back in), the mtrr setting disappears.

[max (maxozilla)]

I can confirm that
echo "base=0xe0000000 size=0x10000000 type=write-combining" > /proc/mtrr
fixes choppy fullscreen flash issues on an Intel Corporation Mobile GME965/GLE960 Integrated Graphics Controller in Ubuntu Jaunty 9.04

[fossfreedom (fossfreedom)]

Francois - similar thread (http://ubuntuforums.org/showpost.php?p=7078262&postcount=35) with one answer I devised - if you find a simpler method please let everyone know. Thanks

[Jesse Barnes (jbarnes-virtuousgeek)]

Yeah, your MTRRs look like they're getting broken. But what's also weird about your config is that GEM isn't getting initialized at all. Why are you using the fake bufmgr? It's going to give you pretty poor performance in general...

[Jesse Barnes (jbarnes-virtuousgeek)]

Also, we're removing EXA support (for many reasons, including performance), so please re-open if you can reproduce this with UXA.

[incubusss (mdv)]

Gem is disabled for i945 and i8xx cards with stock Mandriva 2.6.29.1 kernel due to extremely poor performance when combining them (patch http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/kernel/releases/2.6.29.1/4mnb2/PATCHES/patches/gpu-drm-i915-no-gem-if-no-tiling.patch?view=markup).

Anyway, I've tried with a vanilla 2.6.30rc2-git6 kernel using gem and UXA and I've got exactly the same behavior. I reopen the bug report, edit it and add updated logs.

# lspci -vvv
00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03)
 Subsystem: Lenovo Device 3800
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
 Latency: 0
 Capabilities: [e0] Vendor Specific Information <?>
 Kernel driver in use: agpgart-intel

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
 Subsystem: Lenovo Device 3801
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at d0200000 (32-bit, non-prefetchable) [size=512K]
 Region 1: I/O ports at 1800 [size=8]
 Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
 Region 3: Memory at d0300000 (32-bit, non-prefetchable) [size=256K]
 Expansion ROM at <unassigned> [disabled]
 Capabilities: [90] MSI: Mask- 64bit- Count=1/1 Enable-
  Address: 00000000 Data: 0000
 Capabilities: [d0] Power Management version 2
  Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-
 Kernel modules: intelfb

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
 Subsystem: Lenovo Device 3801
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Region 0: Memory at d0280000 (32-bit, non-prefetchable) [size=512K]
 Capabilities: [d0] Power Management version 2
  Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 PME-Enable- DSel=0 DScale=0 PME-

[incubusss (mdv)]

Created an attachment (id=25017)
Xorg log before restart

[incubusss (mdv)]

Created an attachment (id=25018)
Xorg log after restart

[dentaku65 (dentaku65)]

I've fixed issues with my intel VGA adding VideoRam option in xorg.conf
http://ubuntuforums.org/showpost.php?p=7121605&postcount=34
I did not touch /proc/mtrr

[Yannick Defais (sevmek)]

This bug affect the MSI Wind too:

uptodate Jaunty:

% lspci -vvnn
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae] (rev 03)
 Subsystem: Micro-Star International Co., Ltd. Device [1462:0110]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at dfe80000 (32-bit, non-prefetchable) [size=512K]
 Region 1: I/O ports at d100 [size=8]
 Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
 Region 3: Memory at dff00000 (32-bit, non-prefetchable) [size=256K]
 Capabilities: <access denied>
 Kernel modules: intelfb

% cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f700000 ( 1015MB), size= 1MB, count=1: uncachable
reg02: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable

[incubusss (mdv)]

Using vesa, mtrr are OK.

[molecule-eye (niburu1)]

I can also confirm very choppy fullscreen flash playback and that the fix provided in the original bug report works.

Here is my /proc/mtrr before the fix:

reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f700000 ( 1015MB), size= 1MB, count=1: uncachable
reg02: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable

And my lspci -v:

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
 Subsystem: Gateway 2000 Device 0205
 Flags: bus master, fast devsel, latency 0, IRQ 16
 Memory at d0300000 (32-bit, non-prefetchable) [size=512K]
 I/O ports at 1800 [size=8]
 Memory at c0000000 (32-bit, prefetchable) [size=256M]
 Memory at d0400000 (32-bit, non-prefetchable) [size=256K]
 Capabilities: <access denied>
 Kernel modules: intelfb

After doing a
sudo -s
echo "base=0xc0000000 size=0x10000000 type=write-combining" > /proc/mtrr

my /proc/mtrr now looks like this:
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f700000 ( 1015MB), size= 1MB, count=1: uncachable
reg02: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable
reg03: base=0x0c0000000 ( 3072MB), size= 256MB, count=1: write-combining

Unfortunately the change is not preserved upon reboot, so one has to manually do this "sudo -s..." stuff with each login. (It can be automated, but still...)

[gilipter (marjant)]

how did I fix this?
settings/preferences/compiz config settings manager in the general tab uncheck Unredirect fullscreen windows and that is it, no more choppy full screen video on youtube. hope this helps. marjan.

[Guiodic (Guido Iodice) (guido-iodice)]

Excuse me but I don't understanding how to fix the bug for me!

this is my lspci

Region 0: Memory at b0080000 (32-bit, non-prefetchable) [size=512K]
Region 1: I/O ports at 1800 [size=8]
Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
Region 3: Memory at b0000000 (32-bit, non-prefetchable) [size=256K]

and this my cat /proc/mtrr

reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f700000 ( 1015MB), size= 1MB, count=1: uncachable
reg02: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable

so... what is the right echo string? and why?

Thank you

[molecule-eye (niburu1)]

@Guido: You can do exactly what I did. Type the following in terminal.

sudo -s
echo "base=0xc0000000 size=0x10000000 type=write-combining" > /proc/mtrr

The size=0x10000000 parameter specifies (in hex) 256MB.

[Ryan Fugger (rfugger)]

This fixes Bug #346289 for me:

Choppy Flash playback in full screen.
https://bugs.launchpad.net/ubuntu/+bug/346289

[Gem (gemofgod)]

I also don't understanding how to fix the bug for me.
this is my lspci

00:00.0 Host bridge: Intel Corporation 82Q963/Q965 Memory Controller Hub (rev 02)
00:01.0 PCI bridge: Intel Corporation 82Q963/Q965 PCI Express Root Port (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02)
00:02.1 Display controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02)
00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HB/HR (ICH8/R) LPC Interface Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801H (ICH8 Family) 4 port SATA IDE Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
00:1f.5 IDE interface: Intel Corporation 82801H (ICH8 Family) 2 port SATA IDE Controller (rev 02)
03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02)
04:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)

and this my cat /proc/mtrr

reg00: base=0x000000000 ( 0MB), size=65536MB, count=1: write-back
reg01: base=0x0bf800000 ( 3064MB), size= 8MB, count=1: uncachable
reg02: base=0x0bf700000 ( 3063MB), size= 1MB, count=1: uncachable
reg03: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable

I don't know how to find out the right echo string. Could someone help me?
Thank you

[Tom Chiverton (bugs-launchpad-net-falkensweb)]

It's been three months - what's the plan to fix this (esp. given all the other performance problems [intel] graphics users are having) ?

[molecule-eye (niburu1)]

@Gem: provide your lspci -v output (by typing "lspci -v" in the console) for the VGA Compatible Controller.

[Iain (iain-beeston)]

I'm using Jaunty (UNR) but my /proc/mtrr looks quite different. Not sure if this is something that's been configured by the UNR people or if it's generated by the ubuntu installer, but I have 8 registers defined!

> cat /proc/mtrr
reg00: base=0x0fffe0000 ( 4095MB), size= 128KB, count=1: write-protect
reg01: base=0x0fffc0000 ( 4095MB), size= 128KB, count=1: uncachable
reg02: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg03: base=0x040000000 ( 1024MB), size= 512MB, count=1: write-back
reg04: base=0x05f800000 ( 1528MB), size= 8MB, count=1: uncachable
reg05: base=0x05f600000 ( 1526MB), size= 2MB, count=1: uncachable
reg06: base=0x05f500000 ( 1525MB), size= 1MB, count=1: uncachable
reg07: base=0x000000000 ( 0MB), size= 128KB, count=1: uncachable

[Iain (iain-beeston)]

Sorry, forgot to mention that I'm using a GM945/Acer Aspire One. And I haven't modified /proc/mtrr at all.

[Iain (iain-beeston)]

After a little reading around, I think this might be something to do with the acer bios: apparently it acquires all of the mtrr registers for itself (I've set the mtrr cleanup kernel option and now there are only 4 in /proc/mtrr)

[Gem (gemofgod)]

lspci -v

00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02)
 Subsystem: Dell Device 01da
 Flags: bus master, fast devsel, latency 0, IRQ 2300
 Memory at dfe00000 (32-bit, non-prefetchable) [size=1M]
 Memory at c0000000 (64-bit, prefetchable) [size=256M]
 I/O ports at ecb8 [size=8]
 Capabilities: <access denied>

Is this the right info?

If I've read the rest of them correctly I would think it would be:

sudo -s
echo "base=0xc0000000 size=0x10000000 type=write-combining" > /proc/mtrr

but it gives me the message:

root@ubuntuServer:~# echo "base=0xc0000000 size=0x10000000 type=write-combining" > /proc/mtrr
bash: echo: write error: Invalid argument
root@ubuntuServer:~#

[Iain (iain-beeston)]

I've had a good, long hack away at getting the fix above to stick whenever you log into x (surely there must be a way of doing it through /etc/X11/xinit?) but I can't get it to stay.

My solution has been to create a script containing the above, add that script to sudoers, then make gnome run that in startup applications. Works for me

[Martin Olsson (mnemo)]

Looks like there is more than enough information here to send this to the intel driver developers.

I strongly recommend that someone who experiences this bug and understands the issues opens a high quality bug report at http://bugs.freedesktop.org/ (file against xorg and set component field to Driver/intel). After doing so, connect this bug report to the upstream bug report by clicking the "Also affects project" link at the top of this page.

[Zack Evans (zevans23)]

Guys, I think this explains why 2.6.30RC2 performance is hugely better for me than 2.6.28-11.

I currently have two kernels installed.

2.6.30-020630rc2-generic
2.6.28-11.42-generic

Under the 30RC2 kernel, I see the following in kern.log (good news, I assume!)
Apr 27 10:40:39 vademecum kernel: [ 0.000000] MTRR default type: uncachable
Apr 27 10:40:39 vademecum kernel: [ 0.000000] MTRR fixed ranges enabled:
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 00000-9FFFF write-back
Apr 27 10:40:39 vademecum kernel: [ 0.000000] A0000-BFFFF uncachable
Apr 27 10:40:39 vademecum kernel: [ 0.000000] C0000-DBFFF write-protect
Apr 27 10:40:39 vademecum kernel: [ 0.000000] DC000-E7FFF write-through
Apr 27 10:40:39 vademecum kernel: [ 0.000000] E8000-FFFFF write-protect
Apr 27 10:40:39 vademecum kernel: [ 0.000000] MTRR variable ranges enabled:
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 0 base 000000000 mask 0C0000000 write-back
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 1 base 03F700000 mask 0FFF00000 uncachable
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 2 base 03F800000 mask 0FF800000 uncachable
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 3 disabled
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 4 disabled
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 5 disabled
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 6 disabled
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 7 disabled

Under the 2.6.28 kernel I don't see ANY of that.

2.6.30RC2 /proc/mtrr (good!)
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f700000 ( 1015MB), size= 1MB, count=1: uncachable
reg02: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable
reg03: base=0x0c0000000 ( 3072MB), size= 256MB, count=1: write-combining

2.6.28 /proc/mtrr (bad)
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f700000 ( 1015MB), size= 1MB, count=1: uncachable
reg02: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable

So whatever is done to fix this for 2.6.28 we'll need to be careful about regressions in 2.6.30.

May putting a hack into X startup is not the answer - this looks like a problem with the kernel MTRR startup, especially if this worked right in Intrepid. (If you did want to hack it, then /etc/kde4/kdm/Xsetup or Xstartup would be a good place for Kubuntu.)

[Jesse Barnes (jbarnes-virtuousgeek)]

Created an attachment (id=25246)
Set MTRR even w/WC PCI resources

Can you give this libpciaccess patch a try? It tries to set up an MTRR even if we use the WC files in sysfs (which due to a kernel bug aren't always WC).

[incubusss (mdv)]

(In reply to comment #8)
> Created an attachment (id=25246) [details]
> Set MTRR even w/WC PCI resources
>
> Can you give this libpciaccess patch a try? It tries to set up an MTRR even if
> we use the WC files in sysfs (which due to a kernel bug aren't always WC).
>

This patch is already applied in the libpciaccess I use (0.10.5).

[Bartek (tschew)]

Is this an acceptable automatic hack for the missing MTRR range? I realise there might be a problem when two VGA controllers are present, but at least it does not require user interaction (if run as root).

[molecule-eye (niburu1)]

@Bartek: I haven't looked at the script, but it's extremely easy to add the "echo..." line to your (probably empty) /etc/rc.local file, which will automate the process for you (as already recommended by sunken). However, as noted by Francois, the mtrr entry is reset if you kill X (e.g. by logging out).

[Bartek (tschew)]

@molecule-eye: What I mean by automate is that one does not have to manually hunt for the correct base address and size. With some tweaks it could probably be packaged as a workaround until the drivers are fixed.
The script should be run by the display manager (ie gdm) to ensure persistence.

[Iain (iain-beeston)]

Can I suggest that the script is changed so that if that address is already present in the mtrr then it doesn't add it (otherwise, each time you add it a count variable is incremented). I'm not sure if this could realistically happen if you're running it only when x starts and x clears it when it stops, but it's an easy change to make:

if ! grep -q "base=$address" /proc/mtrr ; then
        echo "base=$address size=$hsize type=write-combining" >| /proc/mtrr && echo success
fi

[Bartek (tschew)]

@Iain: that wouldn't quite work because the base is prefixed with another zero in the /proc/mtrr output (and I'm not sure whether this is always the case), but changing the grep argument to just $address should work. Thank you.

[Bartek (tschew)]

oops, sorry no, of course it wouldn't... hmm, ok how about so

[Ste (stefano-fornari)]

I get the same error as Gem on comment #29 (https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/314928/comments/29) running the command below:

root@miniderfel:~# echo "base=0x03f600000 size=0x10000000 type=write-combining"> /proc/mtrr
bash: echo: write error: Invalid argument

ste

[Bartek (tschew)]

@ste: please read the instructions more carefully, the command is:

echo "base=xxx size=write-combining" >| /proc/mtrr

the pipe is important, so is the space. Also, if the base address you posted above does not work, try removing the extra zero after the x.

Or you could try my script in the post above yours.

[Bartek (tschew)]

oops, sorry, now i mistyped!

I meant: echo "base=xxx size=yyy type=write-combining" >| /proc/mtrr

:)

-Bartek

[Bryce Harrington (bryce)]

This seems to be something requiring a kernel-side change, so assigning a task for linux.

I'm leaving the -intel task open just to make it easier to find and keep track of on the X side, but there is not actually work on the X side to be done for this.

I don't know about the feasibility of a backport to jaunty, however since it would help address some of the performance issues for -intel, it would be nice if the kernel team could look into it.

[Norman Yarvin (yarvin-yarchive)]

That error message "write error: invalid argument" doesn't mean that there was a syntax error. Instead the kernel is rejecting the command. In my case it added a line to dmesg explaining the rejection:

mtrr: type mismatch for d0000000,1000000 old: write-back new: write-combining

That was because there was already an overlapping MTRR entry, covering the first 4GB of address space, describing it as "write-back". The kernel rejects the write-combining MTRR since it overlaps that write-back range. (There are already a bunch of MTRR entries listing uncacheable memory ranges in the first 4GB; but that's permissible, whereas overlap of write-combining and write-back isn't permissible.) This is on an AMD64 machine with 4GB of memory. I did manage to add a write-combining MTRR entry, but only by deleting the entry covering the first 4GB, and replacing it with one 2GB entry and one 1GB entry. This wouldn't be possible on all motherboards; it just happens that on this motherboard, there's no usable memory in the fourth GB of address space; it's all mapped either above or below that.

[Bartek (tschew)]

@Norman: hmm, yes you are indeed right, my apologies to ste

[Norman Yarvin (yarvin-yarchive)]

Having looked into this further, I find that adding the kernel boot parameter "enable_mtrr_cleanup" does exactly what I'd done in replacing the 4GB entry, and for the same purpose (opening up a range where a new write-combining entry can go). Plus, it's a general algorithm, not something specific to this one motherboard. The sanitizer can be selected by default when compiling the kernel (CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1), but Ubuntu doesn't do so.

Looking at this thread:
       http://lkml.org/lkml/2008/4/28/52

it seems that the kernel developers are moving towards using PAT, rather than MTRRs, for the write-combining regions; but the Ubuntu kernel doesn't have PAT enabled.

So people who are getting the "write error: invalid argument" message might try adding that boot parameter.

[Ste (stefano-fornari)]

@Bartek, Norman: the script worked, thanks.

[Eddy (eddy-blum)]

Thanks! Fixed my jerky flash videos.

lspci -v

this gives me 2 entries to my video card amongst others, its the first one I need which tells me the memory region (Memory at d0000000 (32-bit, prefetchable) [size=256M])

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
 Subsystem: Dell Device 0201
 Flags: bus master, fast devsel, latency 0, IRQ 16
 Memory at eff00000 (32-bit, non-prefetchable) [size=512K]
 I/O ports at eff8 [size=8]
 Memory at d0000000 (32-bit, prefetchable) [size=256M]
 Memory at efec0000 (32-bit, non-prefetchable) [size=256K]
 Capabilities: <access denied>
 Kernel modules: intelfb

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
 Subsystem: Dell Device 0201
 Flags: bus master, fast devsel, latency 0
 Memory at eff80000 (32-bit, non-prefetchable) [size=512K]
 Capabilities: <access denied>

my mtrr before:

:~$ cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x07f800000 ( 2040MB), size= 8MB, count=1: uncachable
reg02: base=0x07f700000 ( 2039MB), size= 1MB, count=1: uncachable

I then use the memory region I obtained before and enter

sudo -s
echo "base=0xd0000000 size=0x10000000 type=write-combining" > /proc/mtrr

AFTER:

reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x07f800000 ( 2040MB), size= 8MB, count=1: uncachable
reg02: base=0x07f700000 ( 2039MB), size= 1MB, count=1: uncachable
reg03: base=0x0d0000000 ( 3328MB), size= 256MB, count=2: write-combining

tada!

Fixed, thanks everyone

[JoshAF1986 (joshaf1986)]

Hello

I need help...

I have an acer aspire one A110 with Jaunty netbook remix.
I have already modified the kernel to enable MTRR cleanup (I think... how can I check?)

cat /proc/mtrr
reg00: base=0x0fffe0000 ( 4095MB), size= 128KB, count=1: write-protect
reg01: base=0x0fffc0000 ( 4095MB), size= 128KB, count=1: uncachable
reg02: base=0x000000000 ( 0MB), size= 256MB, count=1: write-back
reg03: base=0x010000000 ( 256MB), size= 256MB, count=1: write-back
reg04: base=0x01f800000 ( 504MB), size= 8MB, count=1: uncachable
reg05: base=0x01f600000 ( 502MB), size= 2MB, count=1: uncachable
reg06: base=0x01f500000 ( 501MB), size= 1MB, count=1: uncachable
reg07: base=0x000000000 ( 0MB), size= 128KB, count=1: uncachable

lspci -v
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
 Subsystem: Acer Incorporated [ALI] Device 015b
 Flags: bus master, fast devsel, latency 0, IRQ 16
 Memory at 38480000 (32-bit, non-prefetchable) [size=512K]
 I/O ports at 60c0 [size=8]
 Memory at 20000000 (32-bit, prefetchable) [size=256M]
 Memory at 38500000 (32-bit, non-prefetchable) [size=256K]
 Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
 Capabilities: [d0] Power Management version 2
 Kernel modules: intelfb

00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
 Subsystem: Acer Incorporated [ALI] Device 015b
 Flags: bus master, fast devsel, latency 0
 Memory at 38400000 (32-bit, non-prefetchable) [size=512K]
 Capabilities: [d0] Power Management version 2

I can't get the fix to work. When I type:

root@joshaf1986-laptop:~# echo "base=0xb0000000 size=0x10000000 type=write-combining" > /proc/mtrr

I get the error message:

bash: echo: write error: No space left on device

My partitions are far from full, I don't know what is wrong.

Please advise.

[Norman Yarvin (yarvin-yarchive)]

I think that message "no space left on device" means your MTRR registers are all used up. (There are only eight of them.)

To check whether MTRR cleanup is enabled, you can run "dmesg | grep MTRR". The cleanup process produces the lines "original variable MTRRs" and then "New variable MTRRs" (as well as a lot of other output).

[Robert Hooker (sarvatt)]

Aspire ones need enable_mtrr_cleanup mtrr_spare_reg_nr=1 added to the boot options.. It's a different bug because they don't have the MTRRs in the first place but marked as a duplicate of this.

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/370552

[Kresimir Krizanic (kresimir-krizanic)]

FYI, the same thing (missing entry in /proc/mmtr) is occuring on
ATI Radeon X1250. Manually adding the missing entry solves
the choppy flash issue.

initial mmtr:

reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x040000000 ( 1024MB), size= 512MB, count=1: write-back
reg02: base=0x060000000 ( 1536MB), size= 256MB, count=1: write-back
reg03: base=0x070000000 ( 1792MB), size= 128MB, count=1: write-back

entry added:

reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x040000000 ( 1024MB), size= 512MB, count=1: write-back
reg02: base=0x060000000 ( 1536MB), size= 256MB, count=1: write-back
reg03: base=0x070000000 ( 1792MB), size= 128MB, count=1: write-back
reg04: base=0x0c0000000 ( 3072MB), size= 256MB, count=2: write-combining

[Andy Whitcroft (apw)]

It appears that the i915 family driver used to insert the mtrr in older kernels and returns in the latest drivers in the 2.6.30-rc series. It appears that the current driver only inserts the mtrr when GEM is being used. Had a go at backporting the fix for this from upstream. I have built kernels with this patch, and they seem to work on my Intel based laptop:

    $ cat /proc/mtrr
    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=0x0be000000 ( 3040MB), size= 32MB, count=1: uncachable
    reg04: base=0x0ffe00000 ( 4094MB), size= 2MB, count=1: write-protect
    reg05: base=0x0bde00000 ( 3038MB), size= 2MB, count=1: uncachable
    reg06: base=0x0d0000000 ( 3328MB), size= 256MB, count=1: write-combining

If those of you who are affected by this could test out the Jaunty kernels below and report back here that would be very helpful. In particular could you report the output of 'cat /proc/mtrr' with the new kernel. Kernels are at the URL below:

    http://people.ubuntu.com/~apw/lp314928-jaunty/

[Andy Whitcroft (apw)]

@Kresimir -- this fix will not help your case as the MTRR handling is driver specific. As this fix for this bug is driver specific, we should get a new bug filed for yours and add a link to this one.

[Luka Renko (lure)]

Andy: your kernel fixes the problem for me (ThinkPad X200s with 4500MHD). No more chopy flash, no need to fixmtrr.sh!

Thanks you very much for looking into this and I hope this fix will get into jaunty-proposed soon.

[Ilya Barygin (randomaction)]

$ lspci | grep -i vga
00:02.0 VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)

Repository kernel:
$ uname -a
Linux corner 2.6.28-12-generic #43-Ubuntu SMP Fri May 1 19:27:06 UTC 2009 i686 GNU/Linux
$ cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable

~lp314928apw1 kernel:
$ uname -a
Linux corner 2.6.28-13-generic #44~lp314928apw1 SMP Wed May 6 08:32:32 UTC 2009 i686 GNU/Linux
$ cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable
reg02: base=0x0e0000000 ( 3584MB), size= 256MB, count=1: write-combining

[Tim Gardner (timg-tpi)]

Already upstream

[wirechief (wirechief)]

cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x07f700000 ( 2039MB), size= 1MB, count=1: uncachable
reg02: base=0x07f800000 ( 2040MB), size= 8MB, count=1: uncachable
then i tried this fix....
sudo sh /usr/local/bin/fixmtrr.sh
Before:
-------
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x07f700000 ( 2039MB), size= 1MB, count=1: uncachable
reg02: base=0x07f800000 ( 2040MB), size= 8MB, count=1: uncachable

After:
------
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x07f700000 ( 2039MB), size= 1MB, count=1: uncachable
reg02: base=0x07f800000 ( 2040MB), size= 8MB, count=1: uncachable
reg03: base=0x0e0000000 ( 3584MB), size= 256MB, count=1: write-combining

Linux wirechief-laptop 2.6.30-020630rc2-generic #020630rc2 SMP Wed Apr
15 13:20:18 UTC 2009 x86_64 GNU/Linux
00:02.0 VGA compatible controller: Intel Corporation Mobile
GM965/GL960 Integrated Graphics Controller (rev 0c)
Ubuntu 9.04 \n \l
ii xserver-xorg-v 2:2.7.99.1+git X.Org X server -- Intel i8xx, i9xx display d

I am not seeing "freeze" or any abnormal operation, i have tested ii
planetpenguin-racer 0.3.1-11
and it runs fine.

i am using a modified xorg.conf with 2048 2048
Section "Screen"
 Identifier "Default Screen"
 Monitor "Configured Monitor"
 Device "Configured Video Device"
        Virtual 2048 2048
EndSection

On Wed, May 6, 2009 at 6:54 AM, Andy Whitcroft <email address hidden> wrote:
> It appears that the i915 family driver used to insert the mtrr in older
> kernels and returns in the latest drivers in the 2.6.30-rc series.  It
> appears that the current driver only inserts the mtrr when GEM is being
> used.  Had a go at backporting the fix for this from upstream.  I have
> built kernels with this patch, and they seem to work on my Intel based
> laptop:
>
>    $ cat /proc/mtrr
>    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=0x0be000000 ( 3040MB), size=   32MB, count=1: uncachable
>    reg04: base=0x0ffe00000 ( 4094MB), size=    2MB, count=1: write-protect
>    reg05: base=0x0bde00000 ( 3038MB), size=    2MB, count=1: uncachable
>    reg06: base=0x0d0000000 ( 3328MB), size=  256MB, count=1: write-combining
>
> If those of you who are affected by this could test out the Jaunty
> kernels below and report back here that would be very helpful.  In
> particular could you report the output of 'cat /proc/mtrr' with the new
> kernel.  Kernels are at the URL below:
>
>    http://people.ubuntu.com/~apw/lp314928-jaunty/
>
> --
> [i915GM] MTRR entry gets removed when restarting xorg - causes corruption on ttys
> https://bugs.launchpad.net/bugs/314928
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Reach out and share life, care for others,

[Zack Evans (zevans23)]

Andy's kernel is a partial fix - but at least it proves the patch is along the right lines...

Netbook Advent 4211 = rebadge of MSI Wind.

$ uname -a
Linux vademecum 2.6.28-13-generic #44~lp314928apw1 SMP Wed May 6 08:32:32 UTC 2009 i686 GNU/Linux

On boot and after first successful X login...
$ cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f700000 ( 1015MB), size= 1MB, count=1: uncachable
reg02: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable
reg03: base=0x0c0000000 ( 3072MB), size= 256MB, count=1: write-combining

After a (clean!) X restart (logged out and restarted from the greeter)...
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f700000 ( 1015MB), size= 1MB, count=1: uncachable
reg02: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable

Have attached my lspci -vvnn.

[bookworm (nofishplease)]

New to Ubuntu. I have been trying to figure out what I need to enter as it seems to be different for each person. Here is what I have

reg00: base=0x000000000 ( 0MB), size= 512MB, count=1: write-back
reg01: base=0x01f700000 ( 503MB), size= 1MB, count=1: uncachable
reg02: base=0x01f800000 ( 504MB), size= 8MB, count=1: uncachable

If some could help me figure out my echo line it would be much appreciated. I tried to compair others but couldn't figure out how the command is generated.

Thanks

[wirechief (wirechief)]

check this link : http://ubuntuforums.org/showthread.php?t=1130582

On Wed, May 6, 2009 at 4:48 PM, bookworm <email address hidden> wrote:
> New to Ubuntu. I have been trying to figure out what I need to enter as
> it seems to be different for each person. Here is what I have
>
> reg00: base=0x000000000 (    0MB), size=  512MB, count=1: write-back
> reg01: base=0x01f700000 (  503MB), size=    1MB, count=1: uncachable
> reg02: base=0x01f800000 (  504MB), size=    8MB, count=1: uncachable
>
> If some could help me figure out my echo line it would be much
> appreciated. I tried to compair others but couldn't figure out how the
> command is generated.
>
> Thanks
>
> --
> [i915GM] MTRR entry gets removed when restarting xorg - causes corruption on ttys
> https://bugs.launchpad.net/bugs/314928
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Reach out and share life, care for others,

[bookworm (nofishplease)]

Thanks wirechief.

[Stefan Bader (smb)]

Confirming the correct setup of MTRR on an Acer Aspire One with an Intel 945GME chipset.

[Bartek (tschew)]

I would like to add emphasis to Zack's point that the fix proposed in the 2.6.28-13.44~lp314928apw1 does not survive an X restart, logout / login procedure or a user switching.

-Bartek

[Bryce Harrington (bryce)]

[Tracking linux status]

[Andy Whitcroft (apw)]

@Bartek, Zack -- yes I see the same. I am tracking the trigger for the removal as it is not the driver which is doing it. Will spin an updated patch when I have that identified and fixed.

[Bartek (tschew)]

I don't know whether I'm stating the obvious but maybe it will help. When the X server is started using 'startx' in user mode and fixmtrr.sh has not been run, the following error message will output to the terminal when X is closed:

----------------------------------------------------

Dropping master
error setting MTRR (base = 0xd0000000, size = 0x10000000, type = 1) Invalid
argument (22)
 ddxSigGiveUp: Closing log

and xorg log has the following final lines:
(WW) intel(0): drmDropMaster failed: Invalid argument
 ddxSigGiveUp: Closing log

----------------------------------------------------

When fixmtrr was run before, the lines look like so:
Dropping master
 ddxSigGiveUp: Closing log

and xorg.log still looks the same.

----------------------------------------------------

[Jesse Barnes (jbarnes-virtuousgeek)]

This patch should keep the X driver from removing the MTRR that the kernel installed, can you give it a try?

diff --git a/src/i830_driver.c b/src/i830_driver.c
index 1887a51..cbf0bd0 100644
--- a/src/i830_driver.c
+++ b/src/i830_driver.c
@@ -2624,7 +2624,9 @@ I830ScreenInit(int scrnIndex, ScreenPtr pScreen, int argc,
        return FALSE;
    }

- i830_fixup_mtrrs(pScrn);
+ /* In a GEM config, the kernel manages MTRRs */
+ if (!pI830->memory_manager)
+ i830_fixup_mtrrs(pScrn);

    pI830->starting = TRUE;

[udippel (udippel)]

Though this might be slightly off-topic, it still is a helper:
Here gmplayer usually crashes NBR, but mplayer 'worked', by stuttering a whole lot.
The first culprit that I found: pulseaudio.
As soon as I ordered it to use sdl or OSS, it played much smoother. (mplayer myfile.avi -ao oss)

Now I wonder if and how to replace pulseaudio; or is it going to break something?

Uwe

[Andy Whitcroft (apw)]

@bryce -- could you give us some insite into the x-servers interaction with the MTRRs here. It appears from the logs in the previous couple of comments that the x-server is also attempting to instigate and remove an MTRR for the AGP aperture. Yet it seems to be failing to create in in our case, but still managing to remove it on exit. There appear to be two errors in behaviour here from xorg:

1) it is removing the AGP mtrr regarless of whether it was it that installed it
2) when there is no mtrr at start it seems to fail to add one dispite trying

Perhaps you can point me to the right place in X or some docs as to the expected behaviour.

[max (maxozilla)]

Just started having this problem since upgrading to Ubuntu 9.04. This is pretty bad - terrible lagging in videos. I hope this is fixed pretty soon.

[incubusss (mdv)]

Sorry for being late, the mail that should have warned me of a new message never reached my mail box.
I didn't know if the patch is still valid against 2.7.1 (I needed to rediff it), but it doesn't change anything unfortunately, I'm still losing reg03 after a X restart with existing errors found in hardware in the log.

I'm currently using x11 server 1.6.1.901, intel driver 2.7.1 and linux kernel 2.6.30-rc7 (mandriva cooker)

[Mike.lifeguard (mikelifeguard)]

@Bryce: Should those experiencing this bug apply the patch you've provided? I guess that's supposed to replace the workaround script provided by Bartek?

Being unfamiliar with launchpad, I also wanted to check that I'm understanding the status correctly: this bug is fixed for Karmic, but not for Jaunty... is a fix planned for Jaunty? Is it possible to get some bleeding-edge <whatever that debdiff patches, which I think is x> in Jaunty, even if it's not "official"?

[Bryce Harrington (bryce)]

Here is a PPA with this patch packaged for jaunty

  https://edge.launchpad.net/~bryceharrington/+archive/magenta

Please test and verify it solves the original issue.

[Bernhard (b.a.koenig)]

Thanks for the patch Bryce. At first glance, this patch seems to have improved my sound and video stuttering.

[incubusss (mdv)]

Created an attachment (id=26502)
xorglog after X restart

[incubusss (mdv)]

Still valid I've redone a test with a vanilla 2.6.30-rc8 kernel and updated the log

[Giovanni Battista Salvietti (giovannibattista-salvietti)]

I went to the ppa, but I see only a karmic repository.... where is the jaunty one?

[Bernhard (b.a.koenig)]

You can just download the deb file and install it on your machine with
"dpkg -i ......."

[Bryce Harrington (bryce)]

It's updated with a jaunty one now.

On Sat, Jun 06, 2009 at 09:20:41PM -0000, Giovanni Battista Salvietti wrote:
> I went to the ppa, but I see only a karmic repository.... where is the
> jaunty one?
>
> --
> [i915GM] MTRR entry gets removed when restarting xorg - causes corruption on ttys
> https://bugs.launchpad.net/bugs/314928
> You received this bug notification because you are a bug assignee.
>
> Status in X.org xf86-video-intel: In Progress
> Status in “linux” source package in Ubuntu: Fix Released
> Status in “xserver-xorg-video-intel” source package in Ubuntu: Fix Released
> Status in linux in Ubuntu Jaunty: In Progress
> Status in xserver-xorg-video-intel in Ubuntu Jaunty: In Progress
> Status in linux in Ubuntu Karmic: Fix Released
> Status in xserver-xorg-video-intel in Ubuntu Karmic: Fix Released
>
> Bug description:
> When comparing /proc/mtrr of intrepid and current jaunty i noticed there is an entry missing.
>
> Intrepid:
> reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1
> reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
> reg02: base=0x5f700000 (1527MB), size= 1MB: uncachable, count=1
> reg03: base=0x5f800000 (1528MB), size= 8MB: uncachable, count=1
> reg04: base=0xb0000000 (2816MB), size= 256MB: write-combining, count=1
>
> Jaunty:
> reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
> reg01: base=0x040000000 ( 1024MB), size= 512MB, count=1: write-back
> reg02: base=0x05f700000 ( 1527MB), size= 1MB, count=1: uncachable
> reg03: base=0x05f800000 ( 1528MB), size= 8MB, count=1: uncachable
>
> So I tried adding it back by using:
> sudo -s
> echo "base=0xb0000000 size=0x10000000 type=write-combining" > /proc/mtrr
>
> I have noticed a few things after adding that entry:
> - glxgears is now about twice as fast (I know its not a real benchmark ;)
> - 2D Performance does not seem affected however (just testing a bit with x11perf/gtkperf)
> - it fixes the corruption on the ttys (bug 312677)
>
> I also noticed that this entry gets removed everytime xorg gets restarted.
>
> But I'm not sure with all the recent changes in memory management if that entry should still be there or not.
>
> -------------
>
> lspci
> 00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
> 00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
> 00:02.1 Display controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
> 00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03)
> 00:1c.2 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 3 (rev 03)
> 00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03)
> 00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03)
> 00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03)
> 00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03)
> 00:1d.7 USB Contr...

[Giovanni Battista Salvietti (giovannibattista-salvietti)]

@Bryce

Sorry, the patch in the ppa doesn't work for me (Jaunty 64bit). It didn't set the mtrr at all. By the way fixmtrr.sh method works.
Here it is my lspci, if it helps....

00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31 Express Integrated Graphics Controller [8086:29c2] (rev 02)
 Subsystem: Holco Enterprise Co, Ltd/Shuttle Computer Device [1297:3106]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 2299
 Region 0: Memory at fdf00000 (32-bit, non-prefetchable) [size=512K]
 Region 1: I/O ports at ff00 [size=8]
 Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
 Region 3: Memory at fdc00000 (32-bit, non-prefetchable) [size=1M]
 Capabilities: <access denied>

[Musthafa Meeran (musthafameeran-deactivatedaccount)]

Thanks for fixmtrr.sh !!.. it solved the slow performance problems in my Intel 945GM running Ubuntu/Kubuntu 9.04.

BTW, I am using the older xserver-xorg-video-intel-2.4.
If I use the default xserver-xorg-video-intel 2.6.3, then fixmtrr.sh fixes the performance issues, but causes screen corruption, which can be clearly noticed when switching windows using Alt+Tab !!

---------------------------------------------------------------------------

kernel version 2.6.28.11.15

lspci -vvnn:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)
 Subsystem: Hewlett-Packard Company Device [103c:30ad]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at f4600000 (32-bit, non-prefetchable) [size=512K]
 Region 1: I/O ports at 4000 [size=8]
 Region 2: Memory at e0000000 (32-bit, prefetchable) [size=256M]
 Region 3: Memory at f4680000 (32-bit, non-prefetchable) [size=256K]
 Capabilities: <access denied>
 Kernel modules: intelfb

cat /proc/mtrr :

reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0xf7f800000 (63480MB), size= 8MB, count=1: uncachable
reg02: base=0x0feda0000 ( 4077MB), size= 128KB, count=1: uncachable
reg03: base=0x0e0000000 ( 3584MB), size= 256MB, count=1: write-combining

[Bryce Harrington (bryce)]

Jesse, a couple people have tested it on the downstream bug. One person indicates it did not affect the issue. The other tester was a bit ambiguous, but thought it might have helped with sound/video stuttering.

[Jesse Barnes (jbarnes-virtuousgeek)]

> --- Comment #14 from Bryce Harrington <email address hidden>
> 2009-06-07 11:23:24 PST --- Jesse, a couple people have tested it on
> the downstream bug. One person indicates it did not affect the
> issue. The other tester was a bit ambiguous, but thought it might
> have helped with sound/video stuttering.

I'll have to come up with a patch to monitor MTRR writes; we must be
clearing an MTRR somewhere but not rewriting it at the next startup.
Though I'm pretty sure if you were able to use GEM this problem would
go away...

[Azarashi (tul-tut)]

lspci -vvnn:
Region 2: Memory at e0000000 (64-bit, prefetchable) [size=256M]

cat /proc/mtrr:
reg01: base=0x0e0000000 ( 3584MB), size= 512MB, count=1: uncachable

/proc/mtrr already has the region but it is not "write-combining". Is there any way to reset it or everything is fine and I shouldn't do anything?

[nandhp (nandhp)]

I can also confirm on my ThinkPad T500 running Jaunty that the deb from the PPA does not resolve stuttering in flash video (e.g. fullscreen Hulu, embedded YouTube), but the fixmtrr shell script does:

/proc/mtrr after installing the deb, before running fixmtrr.sh:
reg00: base=0x07d000000 ( 2000MB), size= 16MB, count=1: uncachable
reg01: base=0x07e000000 ( 2016MB), size= 32MB, count=1: uncachable
reg02: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg03: base=0x07ce00000 ( 1998MB), size= 2MB, count=1: uncachable

After running fixmtrr.sh:
reg00: base=0x07d000000 ( 2000MB), size= 16MB, count=1: uncachable
reg01: base=0x07e000000 ( 2016MB), size= 32MB, count=1: uncachable
reg02: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg03: base=0x07ce00000 ( 1998MB), size= 2MB, count=1: uncachable
reg04: base=0x0d0000000 ( 3328MB), size= 256MB, count=1: write-combining

[Andres Mujica (andres.mujica)]

Reporters, please take into account that the solution for this issue is composed by a kernel patch and a xorg patch.

The first one provided by Andy at http://people.ubuntu.com/~apw/lp314928-jaunty/

The second one provided by Bryce's magenta PPA https://edge.launchpad.net/~bryceharrington/+archive/magenta

The kernel patch sets correctly the MTRR and the Xorg one assures that reloading xorg doesn't wipe it.

Please reporters with the same issue, test both, and confirm here to move those to normal updates (i believe they aren't there yet.)

[Mike.lifeguard (mikelifeguard)]

Isn't the kernal patch applied at some point such that it is present in 2.6.30 release (that's how it's fixed for Karmic)? And wouldn't the xorg fix be present in bleeding-edge code like 2:2.7.99.1+git20090605.66ceedc0-0ubuntu0sarvatt2~jaunty (bryce's magenta PPA seems to be patched 2.6.3)?

[Andres Mujica (andres.mujica)]

Sure Mike, i've should have said Jaunty's reporters.

(the kernel patch applies to 2.6.28 series and the xorg one to the 2.6.3 intel driver, both from Jaunty)

sorry for the confusion.

[nandhp (nandhp)]

Sorry, I missed the fact that the patches were supposed to be applied together. I installed the kernel (which caused dpkg to make a fuss, since it's now out-of-date) alongside the Xorg driver, and it works perfectly.

I hope this will be released into jaunty-updates soon.

[Bernhard (b.a.koenig)]

Yeah, hope so too. I had the feeling that this really improved my performance.

[Aaron Brady (bradya)]

I can confirm that the two packages, along with suggest kernel parameters, fix video on my Aspire One 110L. Can't wait for it to hit real-Jaunty.

[Zack Evans (zevans23)]

I ran your patched kernel for quite some time and it was perfectly stable. I moved X on to xorg-edgers version because I was curious about a few other bugs...

I've just been looking into going back a few versions and doing the testing as you suggest. However my .28 kernel is now

linux-image-2.6.28-13-generic 2.6.28-13.44

which has come from -updates, and dpkg is therefore moaning about older versions. So does this already have the patch in, or should I force the "downgrade" to your kernel for testing, with the hope of turning your patch into the .45 release?

[Wayne Stark (wastark)]

Ive just come across this thread, and am having the same problem on my Dell Inspiron 531, with a Radeon HD2400 Graphics card. Its been bugging me for months. Could anyone tell me if a "fix" has been submitted yet?
 Or could someone, tell me simply what the temporary fix is.
Thanks in advance.

[Giovanni Battista Salvietti (giovannibattista-salvietti)]

Well, the fix has been released. It consists of two patches, one for the kernel, the other for the intel driver.
The problem is that the updates hasn't been released and God knows when they'll release them....
By now you have the choice to mess up your system using PPA kernel and driver or use the fixmtrr patch.....

[Dušan Miletić (karl3)]

huff, is there any way of speeding them up? it's really taking to long considering the fact that fix is already here and that this is a serious issue.

could somebody post a detailed instructions (for mortal users) how to fix it ourselves?

[elgilicious (elginearl-deactivatedaccount)]

I have a MSI MS-1223 (PR201) laptop, which has an Intel GMA X4500 graphics chip, with Ubuntu 9.04 (32-bit) on it.

I fixed the choppy fullscreen Flash playback as follows:

1) sudo apt-get install compizconfig-settings-manager
2) Click "General Options"
3) Remove the check from "Unredirect Fullscreen Windows"

Flash videos should now play smoothly in Firefox in fullscreen mode. I switched to Metacity at this point because my Conky monitors were flashing during playback withh Compiz as the window manager. If you don't use Conky, you shouldn't see this flicker. Use whatever window manager you want.

[Theodore Lee (sharp-shiny)]

AFAIK, this issue still occurs with Compiz disabled or not installed at all (at least, it affects my system that way).

The temporary fix is to download and run the fixmtrr.sh script [1] as root (with 'sudo') every time you start up your system. So for example, if you saved the script in your home directory you'd need to open a terminal window and run 'sudo ~/fixmtrr.sh' (without the quotes) on each login.

I think we'd all appreciate it if the kernel fix arrived soon. =)

[1] http://launchpadlibrarian.net/26193373/fixmtrr.sh

[Jesse Barnes (jbarnes-virtuousgeek)]

Is this still an issue with more recent bits?

[Martin Pitt (pitti)]

Can anyone please test the update in jaunty-proposed and give feedback here?

[Giovanni Battista Salvietti (giovannibattista-salvietti)]

The Xorg update in jaunty-proposed isn't working at all.
IMHO we should close this bug, 'cause the ubuntu team isn't interested at solving it (althought is extremely simple to do).
All in all, we only have to wait 1 more month for karmic....

[Martin Pitt (pitti)]

Well, nothing is simple when it comes to video drivers, I'm afraid :-(, and you just said yourself that the patch doesn't work.,,,

Anyway, thanks for testing. Since the current patch doesn't work, I removed the current package from jaunty-proposed.

[Jesse Barnes (jbarnes-virtuousgeek)]

Assuming this is no longer an issue...

[Jan Girlich (vollkorn)]

Okay, I'm not very active on launchpad, so please forgive me if I'm sounding silly, but: What the heck??

There is this user called "Bug Watch Updater" who just set the status to invalid and I try to understand why, but all I can find out is that this account does not really exists according to https://launchpad.net/~bug-watch-updater, is not mentioned anywhere on http://help.launchpad.net/ and google only turns up with more things Bug Watch Updater does *not* have on launchpad like blueprints, PPAs, questions, assigned bugs and so on.

But he just decided to invalidate this bug, so I guess it's a not very well documented bot acting here?

[Bernhard (b.a.koenig)]

This bug has a "remote bug watch", in this case it's related to a bug in freedesktopbugs (#21303). If that bug is considered invalid, then the bot declares the Ubuntu bug as invalid too.

[Bryce Harrington (bryce)]

[No reason was given for reopening the Karmic task]

[Steve Beattie (sbeattie)]

On Tue, Oct 06, 2009 at 02:09:18AM -0000, Bernhard wrote:
> This bug has a "remote bug watch", in this case it's related to a bug in
> freedesktopbugs (#21303). If that bug is considered invalid, then the
> bot declares the Ubuntu bug as invalid too.

That's not quite correct. The bug watch noticed that the freedesktop
bug #21303 got set to invalid, so it changed the corresponding tracking
state *of the upstream task* in this launchpad bug to match. It did not
change the state of the Ubuntu specific bug task, which had been set to
Fix Released.

--
Steve Beattie
<email address hidden>
http://NxNW.org/~steve/

[v1nsai (v1nsai)]

I don't know how to change the status, but the xserver-xorg-video-intel 2.9 on Ubuntu Karmic is still unclaimed on my Dell Studio 15 when I check 'lshw -C display'.

Performance is still a little laggy, I'm using compiz but a lot of the animations lag pretty easily, and VMware always gives me an error about my video card being incompatible.

I tried rolling back to the 2.4 driver but that didn't fix it and almost fubar'ed my system o_0

[ticket (tickettothemoon2004)]

Although I understand this issue is fixed in karmic, I found that if I issue (under karmic)

  cat /proc/mtrr

I see the output shows that mtrr is not set up.
I can fix it for my gpu card by issuing a

sudo -s
echo "base=0xe0000000 size=0x10000000 type=write-combining" >| /proc/mtrr

If I put the echo command inside /etc/gdm/PostLogin/Default , it is ignored in karmic (wasn't in jaunty). I can make it stick by putting it in /etc/rc.local (but with the provisos noted by the posts above).

With mtrr correctly setup, their is a very slight improvement in flash performance, so it appears to be doing something. I am not using an intel gpu - I have an nVidia one.

My /boot/config-2.6.31-15-generic contains

CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=0
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y

So does this mean I don't need to set up mtrr in karmic? And it is safe to ignore the wrong setup reported by cat /proc/mtrr ?

[Bart Rose (jbrose3)]

This bug seems to be back in Lucid Beta 1 on my Acer One 150.

With a stock boot my dmesg reports:

[ 14.725138] mtrr: no more MTRRs available
[ 14.725148] [drm] MTRR allocation failed. Graphics performance may suffer.

and a cat /proc/mtrr reports:

reg00: base=0x0fffe0000 ( 4095MB), size= 128KB, count=1: write-protect
reg01: base=0x0fffc0000 ( 4095MB), size= 128KB, count=1: uncachable
reg02: base=0x000000000 ( 0MB), size= 512MB, count=1: write-back
reg03: base=0x020000000 ( 512MB), size= 512MB, count=1: write-back
reg04: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable
reg05: base=0x03f600000 ( 1014MB), size= 2MB, count=1: uncachable
reg06: base=0x03f500000 ( 1013MB), size= 1MB, count=1: uncachable
reg07: base=0x000000000 ( 0MB), size= 128KB, count=1: uncachable

If I pass "enable_mtrr_cleanup mtrr_spare_reg_nr=1" to kernel and
echo "base=0x40000000 size=0x10000000 type=write-combining" > /proc/mtrr on boot, then my dmesg reports:

original variable MTRRs
[ 0.000000] reg 0, base: 4194176KB, range: 128KB, type WP
[ 0.000000] reg 1, base: 4194048KB, range: 128KB, type UC
[ 0.000000] reg 2, base: 0GB, range: 512MB, type WB
[ 0.000000] reg 3, base: 512MB, range: 512MB, type WB
[ 0.000000] reg 4, base: 1016MB, range: 8MB, type UC
[ 0.000000] reg 5, base: 1014MB, range: 2MB, type UC
[ 0.000000] reg 6, base: 1013MB, range: 1MB, type UC
[ 0.000000] reg 7, base: 0GB, range: 128KB, type UC
[ 0.000000] WARNING: BIOS bug: VAR MTRR 7 contains strange UC entry under 1M, check with your system vendor!
[ 0.000000] total RAM covered: 1013M
[ 0.000000] Found optimal setting for mtrr clean up
[ 0.000000] gran_size: 64K chunk_size: 16M num_reg: 4 lose cover RAM: 0G
[ 0.000000] New variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 1GB, type WB
[ 0.000000] reg 1, base: 1013MB, range: 1MB, type UC
[ 0.000000] reg 2, base: 1014MB, range: 2MB, type UC
[ 0.000000] reg 3, base: 1016MB, range: 8MB, type UC

and a cat /proc/mtrr reports:

reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f500000 ( 1013MB), size= 1MB, count=1: uncachable
reg02: base=0x03f600000 ( 1014MB), size= 2MB, count=1: uncachable
reg03: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable
reg04: base=0x040000000 ( 1024MB), size= 256MB, count=2: write-combining

This seems like a regression. Please let me know if you need more data.

[Tom Chiverton (bugs-launchpad-net-falkensweb)]

All seems well for me, Intel video hardware and 10.4

[Jeremy Foshee (jeremyfoshee)]

Sebastian,
    Are you able to verify Tom's findings above?

Thanks!

~JFo

[Bart Rose (jbrose3)]

I removed my fix from above to see if this had been fixed for me in subsequent updates and it has not. Here is my output with fixes removed:

bart@bart-laptop:~$ cat /proc/mtrr
reg00: base=0x0fffe0000 ( 4095MB), size= 128KB, count=1: write-protect
reg01: base=0x0fffc0000 ( 4095MB), size= 128KB, count=1: uncachable
reg02: base=0x000000000 ( 0MB), size= 512MB, count=1: write-back
reg03: base=0x020000000 ( 512MB), size= 512MB, count=1: write-back
reg04: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable
reg05: base=0x03f600000 ( 1014MB), size= 2MB, count=1: uncachable
reg06: base=0x03f500000 ( 1013MB), size= 1MB, count=1: uncachable
reg07: base=0x000000000 ( 0MB), size= 128KB, count=1: uncachable

bart@bart-laptop:~$ dmesg | grep MTRR
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] MTRR variable ranges enabled:
[ 14.065032] mtrr: no more MTRRs available
[ 14.065042] [drm] MTRR allocation failed. Graphics performance may suffer.

Tom, which graphics chipset are you using? Mine is a GME945.

[Alex Valavanis (valavanisalex)]

Jaunty reached EOL on 23 October 2010, so no further fixes will be released. This bug has been fixed in more recent versions of Ubuntu