MTRRs set up incorrectly with 4GB RAM -> X slow

[Mika Fischer]

After upgrading my Laptop to 4GB RAM my MTRRs are set up in such a way that X can't set up a write-combining range for the video memory anymore, causing a noticable loss of performance

/proc/mtrr with 2GB:
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x7f700000 (2039MB), size= 1MB: uncachable, count=1
reg02: base=0x7f800000 (2040MB), size= 8MB: uncachable, count=1
reg03: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1
(last range added by X server)

/proc/mtrr with 4GB:
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1

The video memory is at 0xd0000000 (256MB). Note that this range is already included in reg00 and reg01, so the X server cannot set up a write-combining range.

If I manually fix the ranges to look like this:
reg00: base=0xc0000000 (3072MB), size= 256MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg05: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg06: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1

, i.e. explicitly excluding 0xd0000000 (256MB) from both problematic ranges, then the X server can set up the write-combining range again:
reg00: base=0xc0000000 (3072MB), size= 256MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg05: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg06: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1
(last range added by X server)

I'm not sure who is responsible for the MTRRs, BIOS or kernel or both. In case of a broken BIOS, maybe the kernel can sanitize them anyway.

Original description:
-----
Binary package hint: xserver-xorg-video-intel

Today I upgraded my RAM from 1GB to 4GB. Everything worked fine but I noticed that scrolling in Firefox and dragging windows is noticeably slower than before. I checked this again by removing 2GB and got the same results (i.e. 2GB -> fast scrolling, 4GB -> slower scrolling)

I suspect it has to do with this line from the X server:
(WW) intel(0): Failed to set up write-combining range (0xd0000000,0x10000000)

If this is something the kernel is responsible for, please feel free to reassign accordingly.

I have no options in my BIOS to change anything that might be relevant to this (memory mapping, etc.)

This is a Samsung Q45 with Intel X3100 graphics.

I'll attach more debug info.

ProblemType: Bug
Architecture: i386
Date: Wed Apr 2 14:18:58 2008
DistroRelease: Ubuntu 8.04
Package: xserver-xorg-video-intel 2:2.2.1-1ubuntu6
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 PATH=/home/username/bin:/home/username/bin:/home/username/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=de_DE.UTF-8
SourcePackage: xserver-xorg-video-intel
Uname: Linux 2.6.24-12-server i686

[Mika Fischer (zoop)]

Oh, I forgot to add that the problem occurs with the -server and -generic kernels. But I prefer the -server kernels now, because they let me use all 4GB of memory...

My graphics hardware:
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 03)

[Mika Fischer (zoop)]

I can add that this even happens with the 64bit version of hardy beta...

[Mika Fischer (zoop)]

And I can also add that the issue is worse when using Compiz...

[Bryce Harrington (bryce)]

Thanks for attaching all the relevant files. Could you make sure we have Xorg.0.log's from both the 1GB and 4GB configurations? It would be interesting to diff them to see what the x server sees as different.

I think the write-combining range stuff is x server, not the kernel. I could be wrong though.

[Mika Fischer (zoop)]

I won't be able to test with 1GB, because one of the modules requries a substantial effort to replace :)

I have tested it with 2GB (one module), and there the problem also does not occur.

I'll attach the logs but here's the diff (without context) for convenience:
--- Xorg.0.log.2GB 2008-04-03 19:54:14.000000000 +0200
+++ Xorg.0.log.4GB 2008-04-03 19:50:56.000000000 +0200
@@ -23 +23 @@
-(==) Log file: "/var/log/Xorg.0.log", Time: Thu Apr 3 19:53:27 2008
+(==) Log file: "/var/log/Xorg.0.log", Time: Thu Apr 3 19:50:12 2008
@@ -139 +139 @@
- [7] -1 0 0x88000000 - 0x880000ff (0x100) MX[B]
+ [7] -1 0 0xc2000000 - 0xc20000ff (0x100) MX[B]
@@ -168 +168 @@
- [7] -1 0 0x88000000 - 0x880000ff (0x100) MX[B]
+ [7] -1 0 0xc2000000 - 0xc20000ff (0x100) MX[B]
@@ -208 +208 @@
- [11] -1 0 0x88000000 - 0x880000ff (0x100) MX[B]
+ [11] -1 0 0xc2000000 - 0xc20000ff (0x100) MX[B]
@@ -329 +329 @@
- [11] -1 0 0x88000000 - 0x880000ff (0x100) MX[B]
+ [11] -1 0 0xc2000000 - 0xc20000ff (0x100) MX[B]
@@ -364 +364 @@
- [11] -1 0 0x88000000 - 0x880000ff (0x100) MX[B]
+ [11] -1 0 0xc2000000 - 0xc20000ff (0x100) MX[B]
@@ -504 +504 @@
- [13] -1 0 0x88000000 - 0x880000ff (0x100) MX[B]
+ [13] -1 0 0xc2000000 - 0xc20000ff (0x100) MX[B]
@@ -533,2 +533,2 @@
-(II) intel(0): Kernel reported 488960 total, 1 used
-(II) intel(0): I830CheckAvailableMemory: 1955836 kB available
+(II) intel(0): Kernel reported 1006592 total, 1 used
+(II) intel(0): I830CheckAvailableMemory: 4026364 kB available
@@ -571 +571 @@
-(==) intel(0): Write-combining range (0xd0000000,0x10000000)
+(WW) intel(0): Failed to set up write-combining range (0xd0000000,0x10000000)
@@ -689,2 +689,2 @@
-(--) Synaptics Touchpad auto-dev sets device to /dev/input/event7
-(**) Option "Device" "/dev/input/event7"
+(--) Synaptics Touchpad auto-dev sets device to /dev/input/event6
+(**) Option "Device" "/dev/input/event6"
@@ -703,2 +703,2 @@
-(--) Synaptics Touchpad auto-dev sets device to /dev/input/event7
-(**) Option "Device" "/dev/input/event7"
+(--) Synaptics Touchpad auto-dev sets device to /dev/input/event6
+(**) Option "Device" "/dev/input/event6"

[Bryce Harrington (bryce)]

Indeed, you're right, it looks like the write-combining range can' be set up with the larger memory size. Odd. Let's forward this one upstream...

-(II) intel(0): Kernel reported 488960 total, 1 used
-(II) intel(0): I830CheckAvailableMemory: 1955836 kB available
+(II) intel(0): Kernel reported 1006592 total, 1 used
+(II) intel(0): I830CheckAvailableMemory: 4026364 kB available

@@ -568,7 +568,7 @@ drmOpenByBusid: drmGetBusid reports pci:
 (II) intel(0): [drm] Initialized kernel agp heap manager, 33554432
 (II) intel(0): [dri] visual configs initialized
 (II) intel(0): Page Flipping disabled
-(==) intel(0): Write-combining range (0xd0000000,0x10000000)
+(WW) intel(0): Failed to set up write-combining range (0xd0000000,0x10000000)
 (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
 (WW) intel(0): EXA greedy migration mode enabled.
 (II) EXA(0): Forcing greedy migration option

[Bryce Harrington (bryce)]

Mika, I've reported the bug upstream at https://bugs.freedesktop.org/show_bug.cgi?id=15360. Would you mind also subscribing to that bug report, so that if they have additional questions or need more information, you can answer them directly?

Also, I have built some recent git snapshots of the -intel driver here:

  http://people.ubuntu.com/~bryce/bisect/

Would you mind installing and testing the "rac763634" git deb to see if the issue still occurs with a more recent version of the driver?

[Mika Fischer (zoop)]

Bryce, thanks for forwarding the bug. I've subscribed to it.

I've tried the git deb and there are no relevant changes as far as I can see. I'll attach the log and post the diff of 4GB with hardy default driver and 4GB with the git driver below (with hunks with changed dates or input event index removed):

--- Xorg.0.log.4GB 2008-04-03 19:50:56.000000000 +0200
+++ Xorg.0.log.4GB.git20080318.ac763634 2008-04-05 10:24:11.000000000 +0200
@@ -11,7 +11,7 @@
 Release Date: 5 September 2007
 X Protocol Version 11, Revision 0
 Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu6)
-Current Operating System: Linux arthur 2.6.24-12-generic #1 SMP Wed Mar 12 23:01:54 UTC 2008 i686
+Current Operating System: Linux arthur 2.6.24-14-generic #1 SMP Thu Apr 3 04:49:29 UTC 2008 i686
 Build Date: 30 March 2008 04:42:53PM

        Before reporting problems, check http://wiki.x.org
@@ -286,7 +286,7 @@
 (II) LoadModule: "intel"
 (II) Loading /usr/lib/xorg/modules/drivers//intel_drv.so
 (II) Module intel: vendor="X.Org Foundation"
- compiled for 1.4.0.90, module version = 2.2.1
+ compiled for 1.4.0.90, module version = 2.2.0
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 2.0
 (II) LoadModule: "kbd"
@@ -462,6 +462,7 @@
 (==) intel(0): video overlay key set to 0x101fe
 (==) intel(0): Will not try to enable page flipping
 (==) intel(0): Triple buffering disabled
+(==) intel(0): Intel XvMC decoder disabled
 (==) intel(0): Using gamma correction (1.0, 1.0, 1.0)
 (==) intel(0): DPI set to (96, 96)
 (II) Loading sub module "fb"
@@ -553,12 +554,11 @@
 (II) intel(0): [drm] added 1 reserved context for kernel
 (II) intel(0): X context handle = 0x1
 (II) intel(0): [drm] installed DRM signal handler
-(==) intel(0): VideoRam: 262144 KB
 (**) intel(0): Framebuffer compression disabled
 (**) intel(0): Tiling enabled
+(==) intel(0): VideoRam: 262144 KB
 (II) intel(0): Attempting memory allocation with tiled buffers.
-(II) intel(0): Success.
-(II) intel(0): Increasing the scanline pitch to allow tiling mode (3008 -> 3072).
+(II) intel(0): Tiled allocation successful.
 (II) intel(0): [drm] Registers = 0xf0000000
 (II) intel(0): [drm] ring buffer = 0xd0000000
 (II) intel(0): [drm] mapped front buffer at 0xd0100000, handle = 0xd0100000
@@ -612,6 +612,7 @@
 (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message.
 (**) Option "dpms"
 (**) intel(0): DPMS enabled
+(II) intel(0): Set up textured video
 (II) intel(0): Set up overlay video
 (II) intel(0): direct rendering: Enabled
 (--) RandR disabled

[Bryce Harrington (bryce)]

Actually that's good to know - upstream will be interested that the issue still exists in recent git versions, since it'll be something they need to investigate more deeply. It would be good for you to report that to them directly, and attach the new log; seeing proof you're subscribed couldn't hurt either. ;-)

Anyway, agreed, none of the diff looks relevant; nothing changed about the write combining range. Thanks for doing the additional testing.

[Mika Fischer (zoop)]

This is not a bug in X. If at all it's a kernel bug. I'll write a mail to the kernel ML and see what they say. Maybe even the kernel can't fix it and it's just my BIOS that's broken...

In the meantime a workaround is documented here: https://bugs.freedesktop.org/show_bug.cgi?id=15360

I'll also attach the script I use as a workaround.

[Leann Ogasawara (leannogasawara)]

Hi Mika,

Care to provide a reference for the post you made to LKML? Thanks.

[Mika Fischer (zoop)]

Unfortunately I haven't gotten arount to doing that. I'm also not sure whether it's appropriate since I'm not using a stock kernel...

[Greg King (greg-james-king)]

I think this bug and https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/224404 might be the same (however this one is related to the mtrr issue with a fglrx driver). However, if one use the desktop kernel from ubuntu and memory mapping enabled combined with an ATi card (and binary drivers fglrx) the computer crashes (i.e. isn't slow).

[Eric W. Biederman (ebiederm)]

The BIOS is responsible for setting up the MTRRs that map RAM cachable. In some cases it is possible to avoid using
overlapping MTRRs but in general it is not. The only general solution is for X to use the PAT support appearing in linux v2.6.26. I don't know the timeframe for X moving the more general API.

Very little more can be done with MTTRs because of hardware limitations.

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[D. Hugh Redelmeier (hugh-mimosa)]

2.6.27 has been ported to Hardy (a good thing: Hardy is LTS). Unfortunately, it doesn't quite work because v86d is needed. See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/236937/comments/3

I've written an experimental userland program to rejig MTRRs. Read about it here: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/224404/comments/42

It won't always work: there may not be enough MTRRs. If you tell the program the address range you need unnested, it may require fewer MTRRs.

Please send me feedback. Among other information, please include /proc/mtrr

[Rich Hewitt (rich-e-hewitt)]

I just upgraded to Ubuntu 8.10 and I no longer need my manual MTRR fix in /etc/rc.local ... everything is fine using the default config.

[Leann Ogasawara (leannogasawara)]

Mika, since you are the original bug reporter, care to confirm if this is still an issue with Intrepid's final release? Thanks.

[pittipatti (pittipatti)]

Hi Lean,

I'm using the same hardware as the original poster Mika (Samsung Q45, Intel GM965 graphics, 4GB ram) and cannot confirm MTTR's beeing setup correctly in 2.6.27-9-server.

I'm using the server kernel image as the generic kernel only detects 3GB of ram, but that's a different issue.

With 2.6.27-9 the MTTRs are set up like this:

reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1

After applying the changes proposed by the tool mttr-uncover from D. Hugh Redelmeier I get the following layout which allows the X-server to enable write-combining:

reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg05: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1

Is there anything I can test/help to resolve this issue?

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

[George Lesica (oldmanstan)]

This is apparently still a problem with the intrepid generic kernel only i get a different error in dmesg than the original poster:

[ 28.428465] mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining

i went from 1gb to 4gb and my mtrr looks basically the same as the OP and the others with no 256gb section.

[D. Hugh Redelmeier (hugh-mimosa)]

George Lesica: your message appeared in the kernel log (dmesg) whereas the message reported in the first report is from the xorg log. I think that the message in the xorg log might vary between video drivers. The one in kernel log should be consistent.

I'm surprised that you have this problem with intrepid.

Have you tried my mtrr-uncover tool (see above)? You can run it with no risk as a regular user. Give it no arguments. It should print out useful information: what the mtrr's are, what it suggests they could be, and commands to make those changes.

Adding the output here would be informative.

[George Lesica (oldmanstan)]

This is still a problem with 64-bit intrepid. However, the latest mtrr program (from above) seems to solve the problem. I am using the october version of the program rather than the version that is linked to (knock the file name off the end of the address). Now the problem is where to run that program during boot to make it so I don't have to restart X every time I boot up. I will post the output next time I reboot.

[Steven McCoy (dsbunny)]

Affects Dell Hybrid Studio with 4GB system memory In Intrepid, the mtrr-uncover program in rc.local is an effective workaround.

[D. Hugh Redelmeier (hugh-mimosa)]

I have a thinkpad x61t with an intel video chipset. I have installed 4G of RAM.
I am running Intrepid with 64-bit kernel 2.6.27-11-generic.
The Intel X driver works but cannot set the frame buffer to write combining.
glxgears reports 450 FPS.

If I run mtrr-uncover (see above) and restart X, glxgears reports 650 FPS.
So the problem still exists.

[sabby (sabby)]

I add the same problem as George Lesica, except the memory address where different. Everything seem to work fine for me, but the error in dmesg was still bugging me. Note that I didn't see this

mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining

until I updated fglrx, the default in 8.10 does not give me this message. Anyhow, a manual mtrr modification fixed the problem but after a little more digging passing the kernel parameter enable_mtrr_cleanup did also the trick. I found a thread in the lkml talking about setting CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT to 1 by default, which is the same as passing enable_mtrr_cleanup from my understanding, in kernel 2.6.30 because now kernel seem better then X to do the cleanup.

Original thread: http://lkml.org/lkml/2009/2/19/108

For me the performance does not seem to change either way it just get rid of the dmesg error.

[Sven Arvidsson (sa)]

The upstream bug is specific to i386 and is claimed to have been fixed, there's a new one for x86_64 here: http://bugzilla.kernel.org/show_bug.cgi?id=13042

[D. Hugh Redelmeier (hugh-mimosa)]

I'm now using Ubuntu 9.04 on my x61t.

GLXgears now reports varying amounts in the range 900 to 1150 without any mucking with MTRRs. That suggests that the Intel X video driver now uses the PAT mechanism. Good!

The MTRRs are still overlapping.

I had to change mtrr-uncover to deal with a gratuitous change made to the format of /proc/mtrr in kernel 2.6.28. You can get the newer version at ftp://ftp.cs.utoronto.ca/pub/hugh/mtrr-uncover-2009may13.tgz

Interestingly, fixing the MTRRs with mtrr-uncover and restarting X seemed to make glxgears run consistently at about 900. I have no idea why.

Adding "enable_mtrr_cleanup" flag to the appropriate "kernel" line(s) in your /boot/grub/menu.lst will also attempt to eliminate overlapping MTRRs. I don't know which Ubuntu kernel first included the cleanup code but it is in Jaunty's 2.6.28. On my system, the performance effect is the same as if you used mtrr-uncover. Of course it only operates at boot time.

There have been obscure cases where mtrr-uncover worked and enable_mtrr_cleanup did not.

[pittipatti (pittipatti)]

Newer Kernels (e.g. 2.6.28) support the kernel parameter "enable_mtrr_cleanup" which sets up non-overlaping mttr's (at least on my q45).

[Sven Arvidsson (sa)]

It didn't help the reporter of the upstream bug, but it might be a difference between Intel and AMD systems?

Having enable_mtrr_cleanup enabled by default would be good, it was suggested on the lkml, but haven't happend so far? http://lkml.org/lkml/2009/2/19/108

[D. Hugh Redelmeier (hugh-mimosa)]

re mtrr-uncover: I updated it to deal with a change to kernel header <asm/mtrr.h> that hijacked a symbol that I had used.

The link is now ftp://ftp.cs.utoronto.ca/pub/hugh/mtrr-uncover-2009august14.tgz
Best advice: look in that directory for the newest version, indicated by the filename.

[Nigel Pallett (nigelp)]

I have a laptop intel i3 CPU with Intel HD GPU with 6GB ram running Ubuntu 10.10 64 bit.

I get the following error in dmesg:

[drm] MTRR allocation failed. Graphics performance may suffer.

When I run "mtrr-uncover" , I get the following:

Initial MTRR configuration:
 0 0x000000000-0x1ffffffff write-back
         2 0x0dc000000-0x0dfffffff uncachable
         1 0x0e0000000-0x0ffffffff uncachable
         6 0x17c000000-0x17fffffff uncachable
         5 0x19c000000-0x19fffffff uncachable
         4 0x1a0000000-0x1bfffffff uncachable
         3 0x1c0000000-0x1ffffffff uncachable
./mtrr-uncover: 10 MTRRs needed but only 8 in architecture.

Can anyone help me with problem ?

[D. Hugh Redelmeier (hugh-mimosa)]

@Nigel:
Your BIOS has chosen to set up the MTRRs in a way that cannot be fixed by the kernel (or mtrr-uncover) without changing the memory caching ranges.
The BIOS uses overlapping ranges. That won't work when the system wants to change uncachable to write-combining for an X driver.

The kernel (and mtrr-uncover) try to set up equivalent non-overlapping ranges. mtrr-uncover says that to do this it needs more MTRRs than the architecture has.

Newer X drivers don't use MTRRs to do that change. I don't remember what the rules are for the newer "PAT" mechanism. It may be that the problem no longer matters.

I tried to explain much of this in the mtrr-uncover documentation.

1) you could ignore this and hope that performance isn't impacted. You could even test this (perhaps by ditching some RAM)

2) you could figure out another MTRR layout that would work. You would have to figure out if the uncachable range could be made simpler (larger) without breaking anything. Then 8 MTRRs should be enough.

[penalvch (penalvch)]

Mika Fischer, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.