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

Bug #314928 reported by Sebastian Keller on 2009-01-08
292
This bug affects 39 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Invalid
Medium
linux (Ubuntu)
High
Andy Whitcroft
Jaunty
High
Andy Whitcroft
Karmic
High
Andy Whitcroft
xserver-xorg-video-intel (Ubuntu)
High
Unassigned
Jaunty
Critical
Unassigned
Karmic
High
Unassigned

Bug Description

[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) wrote :

[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.

Changed in xserver-xorg-video-intel:
status: New → Incomplete
Sebastian Keller (skeller) wrote :
Sebastian Keller (skeller) wrote :
Changed in xserver-xorg-video-intel:
status: Incomplete → New
Bryce Harrington (bryce) on 2009-01-16
Changed in xserver-xorg-video-intel:
status: New → Confirmed

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

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.

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

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) wrote :

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

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.
>

@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) wrote :

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) wrote :

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

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...

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

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-

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

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

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) wrote :

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

Using vesa, mtrr are OK.

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) wrote :

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.

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) wrote :

@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) wrote :

This fixes Bug #346289 for me:

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

Gem (gemofgod) wrote :

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

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) wrote :

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

Iain (iain-beeston) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.)

Bryce Harrington (bryce) on 2009-05-01
summary: - [i915GM] MTRR entry missing since jaunty - is this intentional?
+ [i915GM] MTRR entry gets removed when restarting xorg - causes
+ corruption on ttys
Changed in linux (Ubuntu Jaunty):
importance: Undecided → High
Changed in linux (Ubuntu Karmic):
importance: Undecided → High
milestone: none → karmic-alpha-2
Changed in xserver-xorg-video-intel (Ubuntu Jaunty):
status: New → Won't Fix
Bryce Harrington (bryce) on 2009-05-01
Changed in xserver-xorg-video-intel (Ubuntu Karmic):
importance: Undecided → High
status: Confirmed → Triaged
Andy Whitcroft (apw) on 2009-05-05
Changed in linux (Ubuntu Karmic):
assignee: nobody → Andy Whitcroft (apw)
status: New → In Progress
Andy Whitcroft (apw) on 2009-05-06
Changed in linux (Ubuntu Jaunty):
assignee: nobody → Andy Whitcroft (apw)
status: New → In Progress
Tim Gardner (timg-tpi) on 2009-05-06
Changed in linux (Ubuntu Karmic):
status: In Progress → Fix Released
Bryce Harrington (bryce) on 2009-05-06
tags: added: corruption
Bryce Harrington (bryce) on 2009-05-07
Changed in xserver-xorg-video-intel (Ubuntu Karmic):
status: Triaged → Fix Released
Bryce Harrington (bryce) on 2009-05-11
Changed in xserver-xorg-video-intel (Ubuntu Jaunty):
status: Won't Fix → Triaged
Bryce Harrington (bryce) on 2009-05-12
Changed in xserver-xorg-video-intel (Ubuntu Jaunty):
assignee: nobody → Bryce Harrington (bryceharrington)
importance: Undecided → Critical
milestone: none → jaunty-updates
status: Triaged → In Progress
Changed in xserver-xorg-video-intel:
status: Unknown → In Progress
Andy Whitcroft (apw) on 2009-05-13
tags: added: regression-release
48 comments hidden view all 128 comments

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

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

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

Download full text (4.2 KiB)

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...

Read more...

@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>

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

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.

> --- 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) wrote :

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) wrote :

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

nandhp (nandhp) wrote :
Andres Mujica (andres.mujica) wrote :

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.)

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) wrote :

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) wrote :

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) wrote :

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

Aaron Brady (bradya) wrote :

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) wrote :

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?

Bryce Harrington (bryce) wrote :
Bryce Harrington (bryce) on 2009-06-27
description: updated
Martin Pitt (pitti) on 2009-06-29
Changed in xserver-xorg-video-intel (Ubuntu Jaunty):
status: In Progress → Fix Committed
Wayne Stark (wastark) wrote :

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.

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) wrote :

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) wrote :

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) wrote :

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

Is this still an issue with more recent bits?

Changed in linux (Ubuntu Karmic):
status: Fix Released → Fix Committed
status: Fix Committed → Fix Released
Martin Pitt (pitti) wrote :

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

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) wrote :

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.

Changed in xserver-xorg-video-intel (Ubuntu Jaunty):
status: Fix Committed → Confirmed

Assuming this is no longer an issue...

Changed in xserver-xorg-video-intel:
status: In Progress → Invalid
Jan Girlich (vollkorn) wrote :

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) 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.

ivan (telejet) on 2009-10-06
Changed in xserver-xorg-video-intel (Ubuntu Karmic):
status: Fix Released → New
Bryce Harrington (bryce) wrote :

[No reason was given for reopening the Karmic task]

Changed in xserver-xorg-video-intel (Ubuntu Karmic):
status: New → Fix Released
Changed in xserver-xorg-video-intel (Ubuntu Jaunty):
assignee: Bryce Harrington (bryceharrington) → nobody

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) wrote :

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) wrote :

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) wrote :

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.

All seems well for me, Intel video hardware and 10.4

Jeremy Foshee (jeremyfoshee) wrote :

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

Thanks!

~JFo

Bart Rose (jbrose3) wrote :

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.

Andy Whitcroft (apw) on 2010-06-18
Changed in linux (Ubuntu Jaunty):
status: In Progress → Won't Fix
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium

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

Changed in xserver-xorg-video-intel (Ubuntu Jaunty):
status: Confirmed → Won't Fix
Changed in xserver-xorg-video-intel:
importance: Medium → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
Displaying first 40 and last 40 comments. View all 128 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.