[PATCH] Mouse cursor dissappears with nouveau

[tdn]

SRU Justification

Impact: Mouse cursor disappears after some time of using the nouveau driver on a computer with NV50 graphics

Fix: Backport of upstream workaround that avoids using the last 32 bytes of the evo ring buffer.

Test case: Verified with natty on LP #583760.

---

Suddenly my mouse cursor dissappeared.

I got this error in the logs:
2010-05-21T13:48:37.658810+02:00 malbec.vineyard.sikkerhed.org kernel: [ 8011.646410] [drm] nouveau 0000:01:00.0: EvoCh 0 Mthd 0x0000 Data 0x00000400 (0x0002 0x01)

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: libdrm-nouveau1 2.4.18-1ubuntu3
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic i686
Architecture: i386
Date: Fri May 21 13:50:02 2010
DkmsStatus:
 virtualbox-ose, 3.1.6, 2.6.32-21-generic, i686: installed
 virtualbox-ose, 3.1.6, 2.6.32-22-generic, i686: installed
GdmLog:
 Error: command ['kdesudo', '--', 'cat', '/var/log/gdm/:0.log'] failed with exit code 1: QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No such file or directory
 QFileSystemWatcher: failed to add paths: /home/tdn/.config/ibus/bus
 Bus::open: Can not get ibus-daemon's address.
 IBusInputContext::createInputContext: no connection to ibus-daemon
 cat: /var/log/gdm/:0.log: No such file or directory
GdmLog1: Error: command ['kdesudo', '--', 'cat', '/var/log/gdm/:0.log.1'] failed with exit code 1: cat: /var/log/gdm/:0.log.1: No such file or directory
GdmLog2: Error: command ['kdesudo', '--', 'cat', '/var/log/gdm/:0.log.2'] failed with exit code 1: cat: /var/log/gdm/:0.log.2: No such file or directory
InstallationMedia: Kubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100427)
MachineType: LENOVO 6460D8G
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.32-22-generic root=/dev/mapper/hostname-root ro quiet splash
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 LANG=en_DK.UTF-8
 SHELL=/bin/zsh
SourcePackage: libdrm
dmi.bios.date: 11/14/2008
dmi.bios.vendor: LENOVO
dmi.bios.version: 7LETC5WW (2.25 )
dmi.board.name: 6460D8G
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr7LETC5WW(2.25):bd11/14/2008:svnLENOVO:pn6460D8G:pvrThinkPadT61p:rvnLENOVO:rn6460D8G:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 6460D8G
dmi.product.version: ThinkPad T61p
dmi.sys.vendor: LENOVO
system:
 distro: Ubuntu
 codename: lucid
 architecture: i686
 kernel: 2.6.32-22-generic

[Gianluca (gianluca-redhat-bugs)]

Nouveau works nicely on my laptop, including suspend and resume, until the power source changes (from AC to battery or from battery to AC).

After that event, mouse pointer gets flaky and I see in /var/log/messages lots of lines like:

Nov 12 01:01:12 localhost kernel: [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Nov 12 01:01:12 localhost kernel: [drm] nouveau 0000:01:00.0: no space while setting cursor image
Nov 12 01:01:12 localhost kernel: [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Nov 12 01:01:14 localhost kernel: [drm] nouveau 0000:01:00.0: no space while setting cursor image
Nov 12 01:01:14 localhost kernel: [drm] nouveau 0000:01:00.0: no space while unhiding cursor

Card is:
nVidia Corporation Quadro NVS 130M [10de:042a]

[Ben (ben-redhat-bugs)]

Is this 100% reproducible on your system, or a random occurance?

[Gianluca (gianluca-redhat-bugs)]

100% reproducible. The timing between power source change and the symptoms varies, but always within minutes I get to the issue.

Right now the only way out seems a reboot, suspending or hibernating leads to a black screen on resume.

[Richard (richard-redhat-bugs)]

I have experienced this same problem on my desktop system a few days ago. I have not used suspend/resume.

xorg-x11-server-Xorg-1.7.1-7.fc12.i686
xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2efd.fc12.i686
xorg-x11-drv-nouveau-debuginfo-0.0.15-17.20091105gite1c2efd.fc12.i686

It's only happened once, but when it happened, my machine got horribly slow. Restarting X "resolved" the issue.

Xorg.0.log and /var/log/messages will be attached...

[Richard (richard-redhat-bugs)]

Created attachment 369809
Xorg.0.log from the session where the cursor problem occured

[Richard (richard-redhat-bugs)]

Created attachment 369810
Relevant /var/log/messages from the session where the cursor problem occured

[Andrew (andrew-redhat-bugs)]

Affects me too. 100% reproducible by doing the following:

1. Set close lid to blank screen
2. Close lid
3. Open lid

It also seems to happen after 30-60 minutes of general usage.

From that point on any cursor change (mouse over anything) creates the following messages and bursts of high CPU usage:

Nov 22 09:58:44 localhost kernel: [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Nov 22 09:58:44 localhost kernel: [drm] nouveau 0000:01:00.0: no space while setting cursor image
Nov 22 09:58:44 localhost kernel: [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Nov 22 09:58:45 localhost kernel: [drm] nouveau 0000:01:00.0: no space while setting cursor image
Nov 22 09:58:45 localhost kernel: [drm] nouveau 0000:01:00.0: no space while unhiding cursor

Card is:
01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 130M (rev a1) (prog-if 00 [VGA controller])
 Subsystem: Toshiba America Info Systems Device 0001
 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, Cache Line Size: 32 bytes
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
 Region 1: Memory at e0000000 (64-bit, prefetchable) [size=256M]
 Region 3: Memory at fa000000 (64-bit, non-prefetchable) [size=32M]
 Region 5: I/O ports at cf00 [size=128]
 [virtual] Expansion ROM at fc000000 [disabled] [size=128K]
 Capabilities: [60] Power Management version 2
  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
  Address: 0000000000000000 Data: 0000
 Capabilities: [78] Express (v1) Endpoint, MSI 00
  DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us
   ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
   RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
   MaxPayload 128 bytes, MaxReadReq 512 bytes
  DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
  LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <512ns, L1 <4us
   ClockPM- Surprise- LLActRep- BwNot-
  LnkCtl: ASPM L0s L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
   ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
  LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
 Capabilities: [100] Virtual Channel <?>
 Capabilities: [128] Power Budgeting <?>
 Capabilities: [600] Vendor Specific Information <?>
 Kernel driver in use: nouveau
 Kernel modules: nouveau, nvidiafb

Rebooting clears this, and doesn't happen with proprietary driver.

[Andrew (andrew-redhat-bugs)]

In my case suspend/resume works to clear it. I get a black screen with cursor on resume (animation at full speed which indicates problem cleared), switching to a console 2 and back to 1 gets the unlock screen. Once unlocked no cursor problems.

So, a sort of workaround for now :)

Also happens switching to battery for me, as the original reporter indicated.

[Tom (tom-redhat-bugs)]

This just happened to me as well - this is a desktop system so no suspend/resume or anything. The machine had been up for about four days (but unused for the last two) and just suddenly started spitting out those messages every time anything tried to change the cursor.

[Gianluca (gianluca-redhat-bugs)]

Tom, which graphic card are you running (use "lspci -nn" to find out)?

[Tom (tom-redhat-bugs)]

The card is:

nVidia Corporation GeForce 8600 GT [10de:0402] (rev a1)

I do have a slightly unusual setup in that I have two monitors attached, one of which is rotated. This has led to one other cursor related problem which is reported in bug #538866.

[Robert (robert-redhat-bugs-1)]

I'm seeing this problem too, on a laptop, takes a while to occur, then my dmesg gets full of those no space while setting/unhiding cursor errors.

lspci output:
01:00.0 VGA compatible controller [0300]: nVidia Corporation GeForce 8400M GS [10de:0427] (rev a1)

dmesg output:
[drm] nouveau 0000:01:00.0: no space while setting cursor image
[drm] nouveau 0000:01:00.0: no space while unhiding cursor
[drm] nouveau 0000:01:00.0: no space while setting cursor image
[drm] nouveau 0000:01:00.0: no space while unhiding cursor

[Ben (ben-redhat-bugs)]

*** Bug 541628 has been marked as a duplicate of this bug. ***

[Ben (ben-redhat-bugs)]

*** Bug 548545 has been marked as a duplicate of this bug. ***

[Kyle (kyle-redhat-bugs)]

I'm seeing similar symptoms.

02:00.0 VGA compatible controller [0300]: nVidia Corporation GT200 [GeForce GTX 260] [10de:05e2] (rev a1)

xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2efd.fc12.x86_64
kernel-2.6.31.6-166.fc12.x86_64

I have a dual screen setup and I'm seeing lots of the "no space while setting cursor image" notices. When moving the mouse from one monitor to the other, the cursor gets "stuck" on the previous monitor. This primarily happens when the cursor changes, ie, when moused over a border to resize a window. When this happens, the stuck cursor appears several hundred pixels higher on the middle border of the screen (in this example, with the "resize" cursor).

[Ben (ben-redhat-bugs)]

Are you guys able to update to kernel-2.6.31.9-174.fc12 (http://koji.fedoraproject.org/koji/buildinfo?buildID=147895) and report how things are.

[Tom (tom-redhat-bugs)]

I've been running on that kernel since last Wednesday, and no sign of any problems so far. It can sometimes take a week or more before it happens though so it may still appear again.

[Gianluca (gianluca-redhat-bugs)]

Hi Ben, I did not realize there were changes related to this in the latest kernel. I just tried unplugging the power cord and my cursor completely disappeared...

However, after a reboot I was not able to reproduce the issue again, so I'm not really sure about the status of this bug. I will test a bit more then let you know how it goes.

Thanks!

[Gianluca (gianluca-redhat-bugs)]

Ben, right it seems the original issue is gone for me.

I think there's more to investigate (for instance, I experienced a black screen with only the mouse visible on a resume after suspend) but I guess I'll open other reports if I manage undestard which usage pattern triggers it.

[Robert (robert-redhat-bugs-1)]

Yup, I've re-tested and this issue seems fixed for me too.

[Miroslav (miroslav-redhat-bugs)]

Experiencing this issue right on Quadro NVS 140m (Thinkpad T61) - dual screen setup with
kernel-2.6.31.12-174.2.3.fc12.x86_64
xorg-x11-drv-nouveau-0.0.15-19.20091105gite1c2efd.fc12.x86_64
Going for newest rawhide kernel, report back if issue won't dissapear
From var log messages:
...
Feb 9 09:31:59 kernel: [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Feb 9 09:31:59 kernel: [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Feb 9 09:32:24 kernel: [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Feb 9 09:32:24 kernel: [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Feb 9 09:32:24 kernel: [drm] nouveau 0000:01:00.0: no space while hiding cursor
Feb 9 09:32:24 kernel: [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Feb 9 09:32:27 kernel: [drm] nouveau 0000:01:00.0: no space while hiding cursor

[Ben (ben-redhat-bugs)]

Miroslav: is this an easily reproducible issue for you? I may have added a fix to nouveau upstream, which'll make it into rawhide soon that will hopefully fix this once and for all. I can't say for sure since none of my cards exhibit the problem for some reason.

The current rawhide kernel has code which'll mostly avoid the issue, making it much harder to reproduce (in theory).

[Miroslav (miroslav-redhat-bugs)]

Ben, it isn't easily reproducible :/. My system was running for several days with kernel-2.6.31.12-174.2.3.fc12 and the bug appeared "from nowhere" there too. I will try the new rawhide kernel when it's build. When it will appear after that, I will report back. Thanks for the info.

[Ben (ben-redhat-bugs)]

*** Bug 562496 has been marked as a duplicate of this bug. ***

[Laurence (laurence-redhat-bugs)]

This problem still happens for me, using the latest upstream git of everything (linux, xorg xorg drivers, etc) as of Feb 18 2010, however it has "improved" a little since earlier. My system chip is Quadro NVS 135M (rev a1).

This kludge to the nouveau driver in linux stops the problems happening for me altogether:

------------------------------------------------------------
--- a/drivers/gpu/drm/nouveau/nv50_cursor.c
+++ b/drivers/gpu/drm/nouveau/nv50_cursor.c
@@ -41,6 +41,14 @@ nv50_cursor_show(struct nouveau_crtc *nv_crtc, bool
update) struct drm_device *dev = nv_crtc->base.dev;
        int ret;

+ static int count = 0;
+
+ if (count > 3) {
+ return;
+ } else {
+ count++;
+ }
+
        NV_DEBUG_KMS(dev, "\n");

        if (update && nv_crtc->cursor.visible)
@@ -76,6 +84,8 @@ nv50_cursor_hide(struct nouveau_crtc *nv_crtc, bool
update) struct drm_device *dev = nv_crtc->base.dev;
        int ret;

+ return;
+
        NV_DEBUG_KMS(dev, "\n");

        if (update && !nv_crtc->cursor.visible)
------------------------------------------------------------

This raises a lot of issues - what was happening is that READ_GET() in
drivers/gpu/drm/nouveau/nouveau_dma.c returned EBUSY. It looks to me that
the performance problems are because of a spin lock - if I try increasing
the timeout int READ_GET() from 100000 to 1000000, the performance problems
get 10 times worse.

Secondly, why are nv50_cursor_show() & nv50_cursor_hide()
in /drivers/gpu/drm/nouveau/nv50_cursor.c being called so often? _show
only needs to be called once per attached monitor, and then _hide only when
it really does need to be hidden, ie. when playing a movie or switching VT
(ie. with the above kludge the mouse cursor stays visible on the VT's), not
every time the mouse cursor changes. It could be even my WM (IceWM) making all those calls, I haven't looked into this further.

I don't have time to look into this further at all.

[Ben (ben-redhat-bugs)]

Show/Hide will get called every time the cursor image is updated, however, they'll actually do nothing unless it needs to change the state, which isn't very often.

The reason it's returning EBUSY is because the display engine is hanging for some, yet unknown, reason. Unfortunately none of my systems appear to display the behaviour so I've not been able to track down what's going on yet.

[Stefan (stefan-redhat-bugs)]

The same is also happening for me with Fedora 13 Alpha (fully updated).

Hardware:
01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 290 (rev a1)
Intel(R) Core(TM)2 Quad CPU Q9400
HP dc7900 (IC10 chipset)

Software:
kernel-2.6.33-1.fc13.x86_64 with no non-Fedora modules
xorg-x11-drv-nouveau-0.0.16-2.20100218git2964702.fc13.x86_64

I have been running Fedora 13 Alpha since the release day, and the problem only happened today after about 4 hours uptime and 2 hours of active work. Something is different today than the days before: I've mounted the debugfs at /sys/kernel/debug, which I have not done before today. It would be a strange connection if this was the culprit, though.

[Stefan (stefan-redhat-bugs)]

I'm running a normal GNOME desktop. It happens when I move the cursor from Firefox to Emacs or vice versa. It does not happen when the cursor moves between Firefox/xterm or Emacs/xterm.

[Stefan (stefan-redhat-bugs)]

Sorry for spamming, but the only messages I get are "no space while hiding cursor", no unhiding or setting cursor image.

[Stefan (stefan-redhat-bugs)]

One more thing - it doesn't have to do with Firefox/emacs/whatever. It happened when I moved the mouse cursor from the left screen to the right one and vice versa.

I have two 24" displays at 1920x1200 attached via DVI.

I've never had this problem with Fedora 12 which I've been running extensively until a few days ago.

[Stefan (stefan-redhat-bugs)]

Created attachment 402070
log excerpt

It happened again today with the same kernel and nouveau versions still. And xorg-x11-server-Xorg-1.7.99.901-8.20100223.fc13.x86_64 (forgot to mention this in comment 26).

When it happened, I tried logging out of the GNOME session which caused both monitors to power down until reboot. I'm attaching an excerpt from /var/log/messages at the time it happened and also the Xorg output, while I'm at it.

[Stefan (stefan-redhat-bugs)]

Created attachment 402071
xorg server log

[Gianluca (gianluca-redhat-bugs)]

Ben, I'm sorry to say this issue is showing itself again, I'm now running the latest F12 bits, kernel-2.6.32.10-90.fc12.x86_64, xorg-x11-drv-nouveau-0.0.15-21.20091105gite1c2efd.fc12.x86_64.

I'm probably going to move on F13 soon so I will be able to say if the same happens there.

[Gianluca (gianluca-redhat-bugs)]

Albeit, I'm noticing a difference: this time only one kind of messages is appearing in /var/log/messages:

Apr 5 01:29:41 localhost kernel: [drm] nouveau 0000:01:00.0: no space while unhiding cursor

[Ben (ben-redhat-bugs)]

*** Bug 593695 has been marked as a duplicate of this bug. ***

[Jerry (jerry-redhat-bugs)]

I originally filed 548545, which was marked as a duplicate of this bug. I just had the same symptom happen: the mouse pointer is no longer drawn when on the left monitor. No messages in /var/log/Xorg.0.log, just this one line in /var/log/messages:

May 28 09:49:10 localhost kernel: [drm] nouveau 0000:03:00.0: EvoCh 0 Mthd 0x0000 Data 0x00000400 (0x0002 0x01)

The mouse pointer is still drawn on the right monitor. This machine is now running F-13, updated this morning. Possibly relevant version numbers:

kernel-2.6.33.4-95.fc13.x86_64
mesa-dri-drivers-7.8.1-6.fc13.x86_64
xorg-x11-drivers-7.3-14.fc13.x86_64
xorg-x11-drv-nouveau-0.0.16-6.20100423git13c1043.fc13.x86_64

Is this really the same bug?

[Jochen Kemnade (jochenkemnade)]

Happens for me too on lucid amd64. This does not happen with the nvidia driver.

27: PCI 200.0: 0300 VGA compatible controller (VGA)
  [Created at pci.318]
  Unique ID: B35A.9kxaXveYaz6
  Parent ID: 3hqH.qNcqIMr0SqF
  SysFS ID: /devices/pci0000:00/0000:00:03.0/0000:02:00.0
  SysFS BusID: 0000:02:00.0
  Hardware Class: graphics card
  Model: "nVidia VGA compatible controller"
  Vendor: pci 0x10de "nVidia Corporation"
  Device: pci 0x060a
  SubVendor: pci 0x1558 "CLEVO/KAPOK Computer"
  SubDevice: pci 0x8687
  Revision: 0xa2
  Driver: "nouveau"
  Driver Modules: "drm"
  Memory Range: 0xce000000-0xceffffff (rw,non-prefetchable)
  Memory Range: 0xd0000000-0xdfffffff (rw,prefetchable)
  Memory Range: 0xcc000000-0xcdffffff (rw,non-prefetchable)
  I/O Ports: 0x2000-0x2fff (rw)
  IRQ: 16 (98 events)
  I/O Ports: 0x3c0-0x3df (rw)
  Module Alias: "pci:v000010DEd0000060Asv00001558sd00008687bc03sc00i00"
  Driver Info #0:
    Driver Status: nouveau is active
    Driver Activation Cmd: "modprobe nouveau"
  Driver Info #1:
    Driver Status: nvidiafb is not active
    Driver Activation Cmd: "modprobe nvidiafb"
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #8 (PCI bridge)

Primary display adapter: #27
02:00.0 VGA compatible controller: nVidia Corporation GT200 [GeForce GTX 280M] (rev a2)
        Subsystem: CLEVO/KAPOK Computer Device 8687
        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, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at ce000000 (32-bit, non-prefetchable) [size=16M]
        Region 1: Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Region 3: Memory at cc000000 (64-bit, non-prefetchable) [size=32M]
        Region 5: I/O ports at 2000 [size=128]
        Capabilities: <access denied>
        Kernel driver in use: nouveau
        Kernel modules: nvidiafb, nouveau

[David (david-redhat-bugs)]

Something similar seems to have recurred in F-13

[drm] nouveau 0000:01:00.0: EvoCh 0 Mthd 0x0000 Data 0x00000400 (0x0002 0x01)

[tdn (spam-thomasdamgaard)]

Is there any hope this will be fixed soon? Or should I just install the proprietary nvidia driver? (are there other alternatives?)

[David (david-redhat-bugs)]

I get the same message as David in comment #36, then the stream of no space messages with jerky window and cursor behaviour.

Fully up-to-date F13,

kernel-2.6.33.5-124.fc13.x86_64
xorg-x11-drv-nouveau-0.0.16-6.20100423git13c1043.fc13.x86_64
xorg-x11-server-Xorg-1.8.0-17.fc13.x86_64

nVidia Corporation G84M [Quadro NVS 140M] (rev a1)

[Donald (donald-redhat-bugs)]

I started getting these messages yesterday, I suspect it was when I experienced a sudden very high load and non-responsiveness - I was running a windows machine inside virtualbox so that I could run gotomeeting, and I was given control of the meeting. When I would click on something in the vm nothing would happen until I moved the mouse out of the virtualbox.
But I've continued to get the messages at a lower rate even after suspending the windows machine.
kernel= 2.6.32.14-127.fc12.x86_64

[Andrew (andrew-redhat-bugs)]

I had this problem a while ago and rolled back nouveau and the problem went away (well it didn't happen again - but of course that's no certainty that the bug was not present in the earlier versions)

The old nouveau that appears to be OK is:
xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2ef
(that's the one I rolled back to when the mouse problem first showed itself)

5 days ago I did a full update that included:
kernel-2.6.32.16-141.fc12.x86_64 and
xorg-x11-drv-nouveau-0.0.15-21.20091105gite1c2efd.fc12.x86_64
and the problem has happened again today (for the first time since the rollback)

Xorg.0.log info:

First nVidia message is:
nVidia Corporation GeForce 8600 GTS rev 161, Mem @ 0xf6000000/16777216, 0xe0000000/268435456, 0xf4000000/33554432, I/O @ 0x0000b000/128, BIOS @ 0x????????/131072

I use a USB mouse, log says:
Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)

I also have a USB Bamboo that the log finds BEFORE the mouse:
Wacom BambooFun 6x8
(I don't use the pen)

The rest of the log looks like status dumps without any error messages.

In my case it's a dual display and acts even stranger when the problem occurs (randomly?):
The left display shows the mouse correctly (but jerky)
In the right display (which has the menu bar) the mouse works but it is invisible
More strange: the mouse image is partially still shown on the edge of the left screen while using the right screen

When the screen saver comes on the mouse is still visible in the left screen
It doesn't fix the problem when the screen comes back
(thought I'd mention that because I've seen it said elsewhere)

It maybe happens when mplayer is playing fullscreen
(so a fullscreen app may be needed to activate the bug)
Of course when the problem wasn't there I was using the current mplayer version constantly also

The first dmesg error was:
[drm] nouveau 0000:01:00.0: EvoCh 0 Mthd 0x0000 Data 0x00000400 (0x0002 0x01)

followed by lots of the cursor messages (both 'hiding' and 'unhiding')

[Andrew (andrew-redhat-bugs)]

Minor updates on previous post:
I only boot runlevel 3 and thus always use startx
(as user "root")

Once the problem has occurred:
X menu System->"Log Out root..." fails to go back to the console
(the screen clears to just showing the backgrounds and then stops)

OS is of course unaffected by this - ssh login works fine
(I use that to "shutdown -r now")

I've rolled back to xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2ef
again (nothing else changed) and will report if it happens again with this
version

Logout messages of Xorg.0.log (before logout stops):

(II) AT Translated Set 2 keyboard: Close
(II) UnloadModule: "evdev"
(II) Macintosh mouse button emulation: Close
(II) UnloadModule: "evdev"
(II) UnloadModule: "wacom"
(II) UnloadModule: "wacom"
(II) UnloadModule: "wacom"
(II) Wacom BambooFun 6x8: removing automatically added devices.
(II) UnloadModule: "wacom"
(II) Microsoft Microsoft 5-Button Mouse with IntelliEye(TM): Close
(II) UnloadModule: "evdev"
(II) Power Button: Close
(II) UnloadModule: "evdev"
(II) Power Button: Close
(II) UnloadModule: "evdev"
(II) NOUVEAU(0): NVLeaveVT is called.
(II) NOUVEAU(0): Closed GPU channel 2

No errors seem to be reported in that log

[Andrew (andrew-redhat-bugs)]

Also now had the same problem occur with the older RPM:
xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2ef

Also, the fullscreen app (mplayer) was not running when it occurred.

Had the same messages for dmesg, /var/log/messages, /var/log/Xorg.0.log as before.
(except no cursor hide/unhide messages)

This time I also got the extra shutdown message (after trying to logout)
dmesg:
[drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing fifo 2
/var/log/messages:
Jul 30 12:34:08 ... kernel: [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing fifo 2

However, I have found another problem with my system that may have something to do with the nouveau bug presenting itself.
My USB mouse is possibly failing and switches on and off sometimes ... easy for me to see while dragging windows around, because it sometimes lets go of a window but I haven't released the left mouse button
(I only realised what was going on after my previous comments)

[David (david-redhat-bugs)]

Created attachment 451152
Provide info on the Evo channel in debugfs

I was able to do some debugging on this issue today, and have a mosly reproducible test case (~90-95%) on my laptop (also using an external monitor). Here's nouveau's spiel about the card on boot of the 2.6.34.7-56.fc13.x86_64 kernel.

[drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x086900a2)
[drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN
[drm] nouveau 0000:01:00.0: ... appears to be valid
[drm] nouveau 0000:01:00.0: BIT BIOS found
[drm] nouveau 0000:01:00.0: Bios version 60.86.68.00
[drm] nouveau 0000:01:00.0: TMDS table revision 2.0 not currently supported
[drm] nouveau 0000:01:00.0: Found Display Configuration Block version 4.0
[drm] nouveau 0000:01:00.0: Raw DCB entry 0: 01000323 00010034
[drm] nouveau 0000:01:00.0: Raw DCB entry 1: 02011300 00000028
[drm] nouveau 0000:01:00.0: Raw DCB entry 2: 02022312 00010010
[drm] nouveau 0000:01:00.0: Raw DCB entry 3: 010333f1 00c0c070
[drm] nouveau 0000:01:00.0: Raw DCB entry 4: 0000000e 00000000
[drm] nouveau 0000:01:00.0: DCB connector table: VHER 0x40 5 14 2
[drm] nouveau 0000:01:00.0: 0: 0x00000041: type 0x41 idx 0 tag 0xff
[drm] nouveau 0000:01:00.0: unknown type, using 0x40
[drm] nouveau 0000:01:00.0: 1: 0x00000100: type 0x00 idx 1 tag 0xff
[drm] nouveau 0000:01:00.0: 2: 0x00001255: type 0x55 idx 2 tag 0x07
[drm] nouveau 0000:01:00.0: unknown type, using 0x31
[drm] nouveau 0000:01:00.0: 3: 0x00000310: type 0x10 idx 3 tag 0xff
[drm] nouveau 0000:01:00.0: 4: 0x00000311: type 0x11 idx 4 tag 0xff
[drm] nouveau 0000:01:00.0: 5: 0x00000313: type 0x13 idx 5 tag 0xff
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xC11C
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xC486
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xD0C7
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xD1B9
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xD3B3
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xD418
[drm] nouveau 0000:01:00.0: 0xD418: Condition still not met after 20ms, skipping following opcodes
[drm] nouveau 0000:01:00.0: 0xB1D6: parsing output script 0
[drm] nouveau 0000:01:00.0: 0xB34C: parsing output script 0
[drm] nouveau 0000:01:00.0: 0xA228: parsing output script 0
[drm] nouveau 0000:01:00.0: Detected 256MiB VRAM
[drm] nouveau 0000:01:00.0: 512 MiB GART (aperture)
[drm] nouveau 0000:01:00.0: DCB encoder 1 unknown
[drm] nouveau 0000:01:00.0: TV-1 has no encoders, removing
[drm] nouveau 0000:01:00.0: gpio tag 0xff not found
[drm] nouveau 0000:01:00.0: gpio tag 0xff not found
[drm] nouveau 0000:01:00.0: Allocating FIFO number 1
[drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 1
[drm] nouveau 0000:01:00.0: allocated 1920x1200 fb: 0x40230000, bo ffff8800790a2400
fbcon: nouveaufb (fb0) is primary device
[drm] nouveau 0000:01:00.0: 0xB083: parsing clock script 0
fb0: nouveaufb frame buffer device
[drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0
[drm] nouveau 0000:01:00.0: 0xB199: parsing clock script 1
[drm] nouveau 0000:01:00.0: 0x1085: parsing clock s...

[Laurence (laurence-redhat-bugs)]

Wow, I'm impressed, many thanks for getting that. FWIW I always have at least 10 xterms open and "xlock -mode blank" is my screensaver, so I always saw the issue after a couple of days at most.

[Steve (steve-redhat-bugs)]

I'm adding a 'me too' to this bug under F13.

Dual Screens, when manifested cursor has issues drawing on left hand screen, appears ok on right hand screen.

lspci;
01:00.0 VGA compatible controller: nVidia Corporation GT216 [GeForce GT 220] (rev a2)

Driver;
xorg-x11-drv-nouveau-0.0.16-8.20100423git13c1043.fc13.i686

happens with 2 hours of a reboot under kernel-PAE-2.6.34.7-56.fc13.i686, can take several days with kernel-PAE-2.6.34.6-54.fc13.i686.

/var/log/messages
Oct 18 11:09:00 cbr-sjw-dt kernel: [drm] nouveau 0000:01:00.0: EvoCh 0 Mthd 0x0000 Data 0x00000400 (0x0002 0x01)

Happy to work with people on this one, it's making this workstation nearly unusable.

[Gianluca (gianluca-redhat-bugs)]

I have not seen the original behaviour I reported since long, but now that I switched to F14 I guess the best course of action is to close this report and let users on a different release (this was for F12, which is EOL in about one month anyway) or different cards from mine open more specific bug reports.

[Stefan (stefan-redhat-bugs)]

Same for me. Has not happened once in a very long time (more than 6 months).

[Andrew (andrew-redhat-bugs)]

Still happening every so often on F12
(I swapped the flaky mouse out long ago)

Current nouveau is:
xorg-x11-drv-nouveau-0.0.15-21.20091105gite1c2efd.fc12.x86_64

Really is annoying sometimes to have to kill everything and shut down to fix the problem

(I've ALWAYS booted 'init 3' on all Linux servers because I don't think graphics drivers should be needed to boot a server ... the drivers for a while now have been forced upon us even during an 'init 3' boot ... but I've also had 'init 3' on all my desktops too ... pity it doesn't help with this problem.
My other F12 desktop - dual screen LCD + TV connected - uses that 'other' driver - obviously due to TV-Out - and though I don't work on it much - just for playing DVD's or other videos - I've still never had this problem with it)

[Jerry (jerry-redhat-bugs)]

I still see the behavior I reported (see comment 35) on F-13 once in awhile. Steve Walsh (comment 44) appears to be seeing the same thing. I'll ask again: is this really the same bug? If not, perhaps bug 548545 should be revived.

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Laurence (laurence-redhat-bugs)]

I use Slackware, this has got nothing to do with Fedora 12, if this bug gets closed I'm giving up on this and switching to the closed nvidia driver.

[Jóhann (jhann-redhat-bugs)]

Please respect the maintainer and dont be rude.

You should be aware of the fact that this bugzilla instance is to be used with RHEL and Fedora only not for everydistro out there so please file your report either to slackware bugzilla instance if they have one or directly upstream with the nouveau maintainers.

However you are welcome to download the latest Fedora release ( 14 ) install it and try to see if you still experience this problem and if so you can make note of that on this bug.

Thank you.

[Gianluca (gianluca-redhat-bugs)]

As the original reporter, I need to note this was for a specific version of nuoveau (the one in F12) with my specific card (with ID in the summary) and that I did not experience anymore mouse movement issues (now I'm on F14, no issues there as well)

If you are running any other combo, I advice to open another, separate report

[David (david-redhat-bugs)]

Created attachment 457771
Band-aid patch that solves the problem for me

Continuing the work I started in comment 42, I was also seeing the "EvoCh 0 Mthd
0x0000 Data 0x00000400 (0x0002 0x01)" messages as everyone else. I did more investigation, and found that not using the last 32 bytes of the Evo ring buffer solved the issue for me -- I no longer get the EvoCh messages, which directly lead to the "no space" messages as seen by the original report and the jerky mouse movements reported by others. This bug is current as of F13, and is likely in F14 and rawhide, as the issue is not yet fixed upstream.

Prior to the patch, dma.max was getting the value 1022. &'ing with ~7 was equivalent to subtracting another 6 entries from that value. I also tried ~3, but that did not fix the issue. I was asked on IRC to try subtracting 5, 4 etc to narrow down the minimum value, and my testing confirmed that subtracting 6 (&= ~7) was minimal. I also tried changing some of the register settings above (NV50_PDISPLAY_CHANNEL_UNK2, etc) but was not successful in teasing out meaning or a fix using them. I have not tried playing with the RAMHT for Evo.

I don't like that my patch involves yet more magic numbers without explanation, but it has been stable for me for the past few weeks, and solves my cursor problem.

[David (david-redhat-bugs)]

Created attachment 457773
Test program that provokes the problem

This program hides/unhides the cursor for the number of cycles given on the command line, default 1. I use this to push the Evo channel's index through the rewind and expose the EvoCh messages. It's much easier than moving the cursor from window to window for a while until things wrap. With my patch, this survives thousands of iterations.

[Gianluca (gianluca-redhat-bugs)]

Reassigning to 13 as suggested by Ben on IRC; that will avoid the auto-close.

[Matthew (matthew-redhat-bugs)]

(In reply to comment #54)
> Created attachment 457773 [details]
> Test program that provokes the problem
>
> This program hides/unhides the cursor for the number of cycles given on the
> command line, default 1. I use this to push the Evo channel's index through the
> rewind and expose the EvoCh messages. It's much easier than moving the cursor
> from window to window for a while until things wrap. With my patch, this
> survives thousands of iterations.

Can you give the list of libs needed to build the program ?

Thanks.

[David (david-redhat-bugs)]

(In reply to comment #56)
> (In reply to comment #54)
> > This program hides/unhides the cursor for the number of cycles given on the
> > command line, default 1. I use this to push the Evo channel's index through the
> > rewind and expose the EvoCh messages. It's much easier than moving the cursor
> > from window to window for a while until things wrap. With my patch, this
> > survives thousands of iterations.
>
> Can you give the list of libs needed to build the program ?
>
> Thanks.

cc -o cycle_cursor -O3 -Wall cycle_cursor.c -lX11

[Stephen M. Webb (bregma)]

I get this problem on a regular basis. Several times a day. It requires a full reboot to reset.

I am running 10.10 on a Thinkpad T410 with an external monitor. The mouse cursor disappears from the built-in display on the laptop but continues to appear on the external monitor. The mouse does, in fact, work on the built-in display but is invisible.

there is nothing abnormal in the Xorg.0.oog, but dmesg always has the following.

[ 8319.721137] [drm] nouveau 0000:01:00.0: EvoCh 0 Mthd 0x0000 Data 0x00000400 (0x0002 0x01)
[ 8607.947182] [drm] nouveau 0000:01:00.0: no space while hiding cursor
[ 8608.059054] [drm] nouveau 0000:01:00.0: no space while hiding cursor
[ 8611.209928] [drm] nouveau 0000:01:00.0: no space while hiding cursor
(this last line is repeated zillions of times).

This bug has also been reported in Fedora <https://bugzilla.redhat.com/show_bug.cgi?id=537065>. That bug has a workaround kernel patch included <https://bugzilla.redhat.com/attachment.cgi?id=457771&action=diff>.

[Laurence (laurence-redhat-bugs)]

David, I've been using your patch in comment 53 and it's resolved the issue for me too, thank you very much.

[Costantino (costantino-redhat-bugs)]

I experienced the same problem on Fedora 14: "no space while unhiding cursor".
This issue is very annoying because the system becomes so slow that I need to restart it.

[Costantino (costantino-redhat-bugs)]

I'd like to test the patch in comment 53, but I cannot find nv50_display.c.
I've installed the kernel sources (yum install kernel-devel) but the folder "/usr/src/kernels/2.6.35.6-48.fc14.x86_64/drivers/gpu/drm/nouveau" is empty.

[Costantino (costantino-redhat-bugs)]

I think that the Severity and Priority for this bug should be higher, because, when it occurs, the system becomes so slow that is almost unusable and on my laptop occurs every day.

My video card is:
01:00.0 VGA compatible controller: nVidia Corporation GT216 [Quadro FX 880M] (rev a2)

[Matthew (matthew-redhat-bugs)]

I'm having the invisible cursor issue and the cycle_cursor app doesn't help with that problem.

I'm not seeing ANY errors in either the .xsession_errors file or in /var/log/messages* .

00:05.0 VGA compatible controller: nVidia Corporation C51G [GeForce 6100] (rev a2)

[Ben (ben-redhat-bugs)]

(In reply to comment #62)
> I'm having the invisible cursor issue and the cycle_cursor app doesn't help
> with that problem.
>
> I'm not seeing ANY errors in either the .xsession_errors file or in
> /var/log/messages* .
>
> 00:05.0 VGA compatible controller: nVidia Corporation C51G [GeForce 6100] (rev
> a2)

This one is actually a hardware bug, and not related in any way.

[Dario (dario-redhat-bugs)]

I don't know if my issue is related to this bug, but on my laptop (Compal JFL92) with a 8600M GT card, kernel 2.6.35.8-60 killed my sound. Pulseaudio no more sees the sound card (HDA Intel) and falls back to dummy audio output. No problem at all with 2.6.35.8-59. I'm not sure if this is the right bug to report it, as the kernel changelog reads:

* Fri Nov 19 2010 Ben Skeggs <email address hidden> 2.6.35.8-60
- nouveau: add quirk for iMac G4 (rhbz#505161)
- nouveau: add workaround for display hang on GF8+ (rhbz#537065)
- nouveau: don't reject 3D object creation on NVAF (MBA3)

but this seems the only one related to my hardware.
dmesg doesn't report anything suspicious, but I'm available for any further testing on this issue.

This on F14 x86_64.

[Matthew (matthew-redhat-bugs)]

(In reply to comment #63)
> (In reply to comment #62)
> > I'm having the invisible cursor issue and the cycle_cursor app doesn't help
> > with that problem.
> >
> > I'm not seeing ANY errors in either the .xsession_errors file or in
> > /var/log/messages* .
> >
> > 00:05.0 VGA compatible controller: nVidia Corporation C51G [GeForce 6100] (rev
> > a2)
>
> This one is actually a hardware bug, and not related in any way.

Odd, Since in Fedora 12 it worked fine (cursor showed up without any issues). It only seemed to happen after a certain point. Next time I have to reboot, I'll swap to an external card vs. the built in video).

[Ben (ben-redhat-bugs)]

(In reply to comment #64)
> I don't know if my issue is related to this bug, but on my laptop (Compal
> JFL92) with a 8600M GT card, kernel 2.6.35.8-60 killed my sound. Pulseaudio no
> more sees the sound card (HDA Intel) and falls back to dummy audio output. No
> problem at all with 2.6.35.8-59. I'm not sure if this is the right bug to
> report it, as the kernel changelog reads:
>
> * Fri Nov 19 2010 Ben Skeggs <email address hidden> 2.6.35.8-60
> - nouveau: add quirk for iMac G4 (rhbz#505161)
> - nouveau: add workaround for display hang on GF8+ (rhbz#537065)
> - nouveau: don't reject 3D object creation on NVAF (MBA3)
>
> but this seems the only one related to my hardware.
> dmesg doesn't report anything suspicious, but I'm available for any further
> testing on this issue.
>
> This on F14 x86_64.
What was your previous kernel? I don't see how these changes could possibly cause what you see.

[Ben (ben-redhat-bugs)]

(In reply to comment #65)
> (In reply to comment #63)
> > (In reply to comment #62)
> > > I'm having the invisible cursor issue and the cycle_cursor app doesn't help
> > > with that problem.
> > >
> > > I'm not seeing ANY errors in either the .xsession_errors file or in
> > > /var/log/messages* .
> > >
> > > 00:05.0 VGA compatible controller: nVidia Corporation C51G [GeForce 6100] (rev
> > > a2)
> >
> > This one is actually a hardware bug, and not related in any way.
>
> Odd, Since in Fedora 12 it worked fine (cursor showed up without any issues).
> It only seemed to happen after a certain point. Next time I have to reboot,
> I'll swap to an external card vs. the built in video).

I guess it's possible something in nouveau now triggers the hw bug more reliably. All previous reports indicate that it would usually come up find, and disappear randomly at some point until a reboot. I used to have the effected hardware (the machine has since died), and even the NVIDIA binary driver could not bring it back once it went.

[Dario (dario-redhat-bugs)]

(In reply to comment #66)
> (In reply to comment #64)
> > I don't know if my issue is related to this bug, but on my laptop (Compal
> > JFL92) with a 8600M GT card, kernel 2.6.35.8-60 killed my sound. Pulseaudio no
> > more sees the sound card (HDA Intel) and falls back to dummy audio output. No
> > problem at all with 2.6.35.8-59. I'm not sure if this is the right bug to
> > report it, as the kernel changelog reads:
> >
> > * Fri Nov 19 2010 Ben Skeggs <email address hidden> 2.6.35.8-60
> > - nouveau: add quirk for iMac G4 (rhbz#505161)
> > - nouveau: add workaround for display hang on GF8+ (rhbz#537065)
> > - nouveau: don't reject 3D object creation on NVAF (MBA3)
> >
> > but this seems the only one related to my hardware.
> > dmesg doesn't report anything suspicious, but I'm available for any further
> > testing on this issue.
> >
> > This on F14 x86_64.
> What was your previous kernel? I don't see how these changes could possibly
> cause what you see.

Previous kernel was 2.6.35-59, and audio still works if I boot it. Yeah I know, it's weird. I'm looking after getting some more info about it, but I doubt I'll have time today...

[Dario (dario-redhat-bugs)]

(In reply to comment #68)
> (In reply to comment #66)
> > (In reply to comment #64)
> > > I don't know if my issue is related to this bug, but on my laptop (Compal
> > > JFL92) with a 8600M GT card, kernel 2.6.35.8-60 killed my sound. Pulseaudio no
> > > more sees the sound card (HDA Intel) and falls back to dummy audio output. No
> > > problem at all with 2.6.35.8-59. I'm not sure if this is the right bug to
> > > report it, as the kernel changelog reads:
> > >
> > > * Fri Nov 19 2010 Ben Skeggs <email address hidden> 2.6.35.8-60
> > > - nouveau: add quirk for iMac G4 (rhbz#505161)
> > > - nouveau: add workaround for display hang on GF8+ (rhbz#537065)
> > > - nouveau: don't reject 3D object creation on NVAF (MBA3)
> > >
> > > but this seems the only one related to my hardware.
> > > dmesg doesn't report anything suspicious, but I'm available for any further
> > > testing on this issue.
> > >
> > > This on F14 x86_64.
> > What was your previous kernel? I don't see how these changes could possibly
> > cause what you see.
>
> Previous kernel was 2.6.35-59, and audio still works if I boot it. Yeah I know,
> it's weird. I'm looking after getting some more info about it, but I doubt I'll
> have time today...

Sorry disregard my bug report, I verified it's a problem with the new dracut update that triggers when a new initramfs is built, not a kernel problem. Coincidentally the two things overlapped on my system. Sorry for wasting your time.

[Costantino (costantino-redhat-bugs)]

As I already asked, how may I find nv50_display.c to try the patch in comment 53?

[Ben (ben-redhat-bugs)]

(In reply to comment #70)
> As I already asked, how may I find nv50_display.c to try the patch in comment
> 53?

You don't need to, it's in kernel-2.6.35.8-60.fc14 (http://koji.fedoraproject.org/koji/buildinfo?buildID=205566)

[Costantino (costantino-redhat-bugs)]

Okay, thanks a lot!
I still have the kernel 2.6.35.6-48.fc14.x86_64.

The kernel-2.6.35.8-60 is still a release candidate. May I install it simple by downloading the rpm or it's better that I wait for the official release (is there already a date?) and then updating with yum?

[Costantino (costantino-redhat-bugs)]

I've now installed the newer kernel (2.6.35.8-60). I let you known, if the problem ("no space while unhiding cursor") occurs again.

[Costantino (costantino-redhat-bugs)]

I'm using the newer kernel (2.6.35.8-60) for about one month and I haven't experienced the problem above ("no space while unhiding cursor") any more.

In my opinion this problem is fixed. Thanks a lot!

[Delan Azabani (azabani)]

After a while (I'm not sure how long) using nouveau, something happens which causes all of these symptoms to begin:

1. cursor movments become jerky
2. moving cursor from one screen to another leaves a copy of the cursor on the first screen
3. syslog shows many lines of "nouveau 0000:01:00.0: no space while hiding cursor"
4. switching to a text VT 'hangs' the display (showing the X screen still) and switching back 'unhangs' display (while on a text VT, though you can't see anything, you can do things 'blindly')
5. restarting X leaves the screen 'hung' with no ability to SysRq+REISUB (keyboard is fully locked up)

A while after the above happens, the entire system will become unresponsive (though background process like RAID resync or torrent continue), and the keyboard doesn't work at all. The only thing that works is moving the mouse cursor.

Reproducible: Always

Steps to Reproduce:
1. use a computer with the nouveau driver for 'a while'
Actual Results:
Please see 'description'.

Expected Results:
No loss of stability over time.

Linux delan2 2.6.38-rc2-delan2+ #5 SMP Fri Jan 28 16:21:14 WST 2011 x86_64 Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz GenuineIntel GNU/Linux

Kernel is from torvalds/linux-2.6.git, though this did still occur with gentoo-sources-2.6.37.

x11-base/xorg-server-1.9.3.901-r1 from gentoo
x11-drivers/xf86-video-nouveau-0.0.16_pre20101130 from gentoo

[Wormo (wormo)]

Have you tried disabling hardware cursor yet?

Option "HWCursor" "false"

Also should be worth trying this patch:
https://bugzilla.redhat.com/attachment.cgi?id=457771

[Delan Azabani (azabani)]

With hardware cursor disabled my cursor flickers heavily and is most of the time invisible. I'm using the default X cursors (the black one, no special cursors like DMZ installed).

The xorg.conf I tried:

Section "Device"
    Identifier "gtx260"
    Driver "nouveau"
    Option "HWCursor" "false"
EndSection

Also, if I understand correctly, that patch was for kernels before somewhere around 2.6.35, right? Just by eyeing my nv50_display.c I can see that the patch probably wouldn't apply anymore on my 2.6.38-rc3 tree.

[Delan Azabani (azabani)]

I have tried to patch nv50_display.c but it failed:

File to patch: drivers/gpu/drm/nouveau/nv50_display.c
patching file drivers/gpu/drm/nouveau/nv50_display.c
Hunk #1 FAILED at 344.
1 out of 1 hunk FAILED -- saving rejects to file drivers/gpu/drm/nouveau/nv50_display.c.rej

If it helps, here's my new uname and some related lspci -vvvnn:

Linux delan2 2.6.38-rc3-delan2 #24 SMP Tue Feb 1 13:35:10 WST 2011 x86_64 Intel(R) Core(TM)2 Quad CPU Q9650 @ 3.00GHz GenuineIntel GNU/Linux

01:00.0 VGA compatible controller [0300]: nVidia Corporation GT200 [GeForce GTX 260] [10de:05e2] (rev a1) (prog-if 00 [VGA controller])
 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, Cache Line Size: 4 bytes
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at fa000000 (32-bit, non-prefetchable) [size=16M]
 Region 1: Memory at e0000000 (64-bit, prefetchable) [size=256M]
 Region 3: Memory at f8000000 (64-bit, non-prefetchable) [size=32M]
 Region 5: I/O ports at bf00 [size=128]
 [virtual] Expansion ROM at fb000000 [disabled] [size=512K]
 Capabilities: [60] Power Management version 3
  Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
  Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
 Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+
  Address: 0000000000000000 Data: 0000
 Capabilities: [78] Express (v1) Endpoint, MSI 00
  DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <1us, L1 <4us
   ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
  DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
   RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
   MaxPayload 128 bytes, MaxReadReq 512 bytes
  DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
  LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <1us, L1 <1us
   ClockPM- Surprise- LLActRep- BwNot-
  LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk-
   ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
  LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
 Kernel driver in use: nouveau

[Delan Azabani (azabani)]

By the way, this problem still occurs with the latest nouveau as built in the latest linux-next git kernel. Apparently git.freedesktop has an even newer nouveau so I might try that. Unless the bug is actually in the xorg driver for nouveau?

[Delan Azabani (azabani)]

Although the keyboard is fully non-operational (no VTs!) and the mouse cursor only moves but doesn't work once the hang occurs, SSH and network still work, and I received these four lines on /var/log/messages the moment nouveau hung:

Feb 12 11:51:03 delan2 kernel: [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_CCACHE FAULT
Feb 12 11:51:03 delan2 kernel: [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_CCACHE 00000000 00000000 00000000 00000000 00000000 00000000 00000000
Feb 12 11:51:03 delan2 kernel: [drm] nouveau 0000:01:00.0: PGRAPH - TRAP
Feb 12 11:51:03 delan2 kernel: [drm] nouveau 0000:01:00.0: PGRAPH - ch 2 (0x0000b00000) subc 5 class 0x8397 mthd 0x0f04 data 0x00000000

I have also seen it vary slightly on the mthd (which has been 0x1414) and the data (which has been 0x00000100). Having searched this error and found basically nothing, this may be important in determining the problem that causes nouveau to hang.

[Chi-Thanh Christopher Nguyen (chithanh)]

You can try xf86-video-nouveau-9999 from the x11 overlay, if the problem still exists with that one, it is probably best to report a bug on https://bugs.freedesktop.org/ too.

[Delan Azabani (azabani)]

I am already using =xf86-video-nouveau-9999 from the x11 overlay. Tomorrow I will report the bug to freedesktop.

[Delan Azabani (azabani)]

Sorry, I didn't make that clear in my original post. Since reporting the bug, I have installed all-9999 packages from the x11 overlay (including xorg-server, xorg-drivers and xf86-video-nouveau, etc. are all 9999 versions) and the problem still occurs.

[Amit Kucheria (amitk)]

Seen on up to date natty too.

[John Clemens (clemej)]

Still occurring with the latest Natty.

Fedora is now including the work around patch in their stock kernels (called drm-nouveau-evo-hang.patch). I've been running this patch on top of the stock ubuntu kernels for months now with no negative side effect. The impact of the patch is low, as its with an experimental driver anyway. Without it, the system becomes nearly unusable when enough cursor hides/unhides happen which cause the buffer to wrap. The only thing the workaround does is shrink the size of the buffer by a few entries.

While I would like a real fix, one doesn't appear to be coming from upstream anytime soon. The impact is low, the benefits are high, its an isolated patch that will only affect users with that hardware. Can we -please- get this workaround patch into a natty kernel update, or, at the very least into oneric's(sp?) kernel?

The patch ported from fedora would be in driver/gpu/drm/nouveau/nv50_evo.c, approx. lilne 184:

 /* enable error reporting on the channel */
 nv_mask(dev, 0x610028, 0x00000000, 0x00010001 << id);

 evo->dma.max = (4096/4) - 2
+ evo->dma.max &= ~7;
 evo->dma.put = 0;
 evo->dma.cur = evo->dma.put;
 evo->dma.free = evo->dma.max - evo->dma.cur;

original patch from fedora 14:

From d0301ece9e093c484f880893dc86d97848360892 Mon Sep 17 00:00:00 2001
From: Ben Skeggs <email address hidden>
Date: Fri, 19 Nov 2010 18:50:57 +1000
Subject: [PATCH 2/2] drm-nouveau-evo-hang

On some GF8+ boards, the display engine will stop processing its push
buffer if a wrap-around occurs at a certain point. The exact cause
is not known.

This patch by David Dillow (rhbz#537065) is a safe enough work-around
until it can be solved properly.

Signed-off-by: Ben Skeggs <email address hidden>
---
 drivers/gpu/drm/nouveau/nv50_display.c | 1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c
index 11d366a..4e5402c 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -364,6 +364,7 @@ nv50_display_init(struct drm_device *dev)
  nv_wr32(dev, 0x610300, nv_rd32(dev, 0x610300) & ~1);

  evo->dma.max = (4096/4) - 2;
+ evo->dma.max &= ~7;
  evo->dma.put = 0;
  evo->dma.cur = evo->dma.put;
  evo->dma.free = evo->dma.max - evo->dma.cur;
--
1.7.3.2

[Bryce Harrington (bryce)]

Since it's a kernel patch, the kernel team needs to take a look at it.

@JFo, please add to the kernel team list to look at for oneiric (and maybe a natty backport).

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Bug (bug-redhat-bugs)]

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Seth Forshee (sforshee)]

Has anyone tried oneiric to see if this problem still exists there? The upstream bug this issue is linked to is marked as having been fixed, and the oneiric version of xserver-xorg-video-nouveau contains the fix identified there. Before applying a workaround in the kernel I'd like to know whether or not a proper fix is available.

This is the fix identified in the upstream bug:

http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/commit/?id=8378443bd3b26b57ef2ae424a700e01ead813d33

[Seth Forshee (sforshee)]

Ignore my request to test oneiric -- it should work, as the work-around fix was already merged into the mainline kernel in 2.6.39. Since the patch is upstream it shouldn't be a problem to pull it in. I've started test builds, and I'll post links for verification when they're done.

[Seth Forshee (sforshee)]

Test builds now available. Please test report your results back here. Thanks!

Lucid:
http://people.canonical.com/~sforshee/lp583760/linux-2.6.32-33.69~lp583760v201107071544/

Maverick:
http://people.canonical.com/~sforshee/lp583760/linux-2.6.35-30.55~lp583760v201107071554/

Natty:
http://people.canonical.com/~sforshee/lp583760/linux-2.6.38-10.46~lp583760v201107071538/

[John Clemens (clemej)]

Thanks you, testing now. Its a work machine though so I can't really play until next week.

[John Clemens (clemej)]

I've been running the seth's kernel (natty amd64) all week with no regressions. Changed back to confirmed.

[Seth Forshee (sforshee)]

The patch that fixes this is already in oneiric, so closing the main task. Added tasks for lucid, maverick, and natty.

[Seth Forshee (sforshee)]

Patches sent to kernel-team mailing list.

[Herton R. Krzesinski (herton)]

This bug is awaiting verification that the kernel for maverick in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-maverick' to 'verification-done-maverick'.

If verification is not done by one week from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Steve Conklin (sconklin)]

This bug is awaiting verification that the kernel for Lucid in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-lucid' to 'verification-done-lucid'.

If verification is not done by one week from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[Steve Conklin (sconklin)]

This fix has not been verified as being fixed in the -proposed kernels for Lucid or Maverick, and the patch will be reverted from those series

[Herton R. Krzesinski (herton)]

This bug is awaiting verification that the kernel for Natty in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-natty' to 'verification-done-natty'.

If verification is not done by one week from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

[John Clemens (clemej)]

I've been running the proposed kernel from natty for the past week-ish with no issues. Now to figure out how to change "tags"...

[Quinn Plattel (qiet72)]

I have also had the same problems reported in this bug report. My setup is:
OS: Ubuntu Maverick 10.10 64-bit
Kernel: 2.6.35-30-generic
Video: 01:00.0 VGA compatible controller: nVidia Corporation G92 [GeForce 8800 GT] (rev a2)
Monitors: Dual ASUS VK266H in DVI-D mode.

When the mouse cursor dissapears on my primary screen but still works on my secondary screen, the follow dmesg occurs:

--------------------------------------
Sep 8 21:37:04 qpp-iscsi-maverick64 kernel: [18105.406442] [drm] nouveau 0000:01:00.0: EvoCh 0 Mthd 0x0000 Data 0x00000400 (0x0002 0x01)
Sep 8 21:54:22 qpp-iscsi-maverick64 kernel: [19144.134753] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:22 qpp-iscsi-maverick64 kernel: [19144.204525] [drm] nouveau 0000:01:00.0: no space while hiding cursor
Sep 8 21:54:22 qpp-iscsi-maverick64 kernel: [19144.278499] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:23 qpp-iscsi-maverick64 kernel: [19145.047375] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:23 qpp-iscsi-maverick64 kernel: [19145.127030] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:24 qpp-iscsi-maverick64 kernel: [19145.719052] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:24 qpp-iscsi-maverick64 kernel: [19145.807039] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:30 qpp-iscsi-maverick64 kernel: [19151.475054] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:30 qpp-iscsi-maverick64 kernel: [19152.003313] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:31 qpp-iscsi-maverick64 kernel: [19152.923499] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:31 qpp-iscsi-maverick64 kernel: [19153.005741] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:32 qpp-iscsi-maverick64 kernel: [19153.287133] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:32 qpp-iscsi-maverick64 kernel: [19153.367768] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:32 qpp-iscsi-maverick64 kernel: [19153.911544] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:32 qpp-iscsi-maverick64 kernel: [19153.991517] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:33 qpp-iscsi-maverick64 kernel: [19155.265350] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:34 qpp-iscsi-maverick64 kernel: [19155.344138] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:34 qpp-iscsi-maverick64 kernel: [19155.815973] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:34 qpp-iscsi-maverick64 kernel: [19155.895518] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:40 qpp-iscsi-maverick64 kernel: [19161.432130] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:40 qpp-iscsi-maverick64 kernel: [19161.511591] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
Sep 8 21:54:46 qpp-iscsi-maverick64 kernel: [19168.272217] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
----------------...

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.35-30.59

---------------
linux (2.6.35-30.59) maverick-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #837449

  [ Upstream Kernel Changes ]

  * Revert "drm/nv50-nvc0: work around an evo channel hang that some people
    see"
  * Revert "eCryptfs: Handle failed metadata read in lookup"

linux (2.6.35-30.58) maverick-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #828376

  [ Upstream Kernel Changes ]

  * proc: fix oops on invalid /proc/<pid>/maps access, CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020

linux (2.6.35-30.57) maverick-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #823306

  [ Tim Gardner ]

  * SAUCE: rtl8192se: Force a build for a 2.6/3.0 kernel
    - LP: #805494
  * [Config] Add enic/fnic to udebs
    - LP: #801610

  [ Upstream Kernel Changes ]

  * taskstats: don't allow duplicate entries in listener mode,
    CVE-2011-2484
    - LP: #806390
    - CVE-2011-2484
  * dccp: handle invalid feature options length, CVE-2011-1770
    - LP: #806375
    - CVE-2011-1770
  * eCryptfs: Handle failed metadata read in lookup
    - LP: #509180
  * pagemap: close races with suid execve, CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020
  * report errors in /proc/*/*map* sanely, CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020
  * close race in /proc/*/environ, CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020
  * auxv: require the target to be tracable (or yourself), CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020
  * deal with races in /proc/*/{syscall, stack, personality}, CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020
  * rose: Add length checks to CALL_REQUEST parsing, CVE-2011-1493
    - LP: #816550
    - CVE-2011-1493
  * Bluetooth: l2cap and rfcomm: fix 1 byte infoleak to userspace.
    - LP: #819569
    - CVE-2011-2492
  * drm/nv50-nvc0: work around an evo channel hang that some people see
    - LP: #583760
 -- Herton Ronaldo Krzesinski <email address hidden> Tue, 30 Aug 2011 12:11:13 -0300

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.38-11.50

---------------
linux (2.6.38-11.50) natty-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #848246

  [ Upstream Kernel Changes ]

  * Revert "eCryptfs: Handle failed metadata read in lookup"
  * Revert "KVM: fix kvmclock regression due to missing clock update"
  * Revert "ath9k: use split rx buffers to get rid of order-1 skb
    allocations"

linux (2.6.38-11.49) natty-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #836903

  [ Adam Jackson ]

  * SAUCE: drm/i915/pch: Fix integer math bugs in panel fitting
    - LP: #753994

  [ Keng-Yu Lin ]

  * SAUCE: Input: ALPS - Enable Intellimouse mode for Lenovo Zhaoyang E47
    - LP: #632884, #803005

  [ Stefan Bader ]

  * [Config] Force perf to use libiberty for demangling
    - LP: #783660

  [ Tim Gardner ]

  * [Config] Add enic/fnic to udebs
    - LP: #801610

  [ Upstream Kernel Changes ]

  * eeepc-wmi: add keys found on EeePC 1215T
    - LP: #812644
  * eCryptfs: Handle failed metadata read in lookup
    - LP: #509180
  * pagemap: close races with suid execve, CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020
  * report errors in /proc/*/*map* sanely, CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020
  * close race in /proc/*/environ, CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020
  * auxv: require the target to be tracable (or yourself), CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020
  * deal with races in /proc/*/{syscall, stack, personality}, CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020
  * vmscan: fix a livelock in kswapd
    - LP: #813797
  * mmc: Add PCI fixup quirks for Ricoh 1180:e823 reader
    - LP: #773524
  * mmc: Added quirks for Ricoh 1180:e823 lower base clock frequency
    - LP: #773524
  * rose: Add length checks to CALL_REQUEST parsing, CVE-2011-1493
    - LP: #816550
    - CVE-2011-1493
  * pata_marvell: Add support for 88SE91A0, 88SE91A4
    - LP: #777325
  * GFS2: make sure fallocate bytes is a multiple of blksize, CVE-2011-2689
    - LP: #819572
    - CVE-2011-2689
  * Bluetooth: l2cap and rfcomm: fix 1 byte infoleak to userspace.
    - LP: #819569
    - CVE-2011-2492
  * drm/nv50-nvc0: work around an evo channel hang that some people see
    - LP: #583760
  * KVM: fix kvmclock regression due to missing clock update
    - LP: #795717
  * Add mount option to check uid of device being mounted = expect uid,
    CVE-2011-1833
    - LP: #732628
    - CVE-2011-1833
  * proc: fix oops on invalid /proc/<pid>/maps access, CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020
  * ipv6: make fragment identifications less predictable, CVE-2011-2699
    - LP: #827685
    - CVE-2011-2699
  * ath9k: use split rx buffers to get rid of order-1 skb allocations
    - LP: #728835
  * perf: Fix software event overflow, CVE-2011-2918
    - LP: #834121
    - CVE-2011-2918
 -- Herton Ronaldo Krzesinski <email address hidden> Mon, 12 Sep 2011 17:23:38 -0300

[Quinn Plattel (qiet72)]

Hi,

After 10 days of testing patched kernel 2.6.35-30-generic #55~lp583760v201107071554ller (rev 10), I think I can safely say that the patch works - no hidden mouse pointers!

br,
Quinn

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.32-34.77

---------------
linux (2.6.32-34.77) lucid-proposed; urgency=low

  [Steve Conklin]

  * Release Tracking Bug
    - LP: #849228

  [ Upstream Kernel Changes ]

  * Revert "drm/i915: Remove BUG_ON from i915_gem_evict_something"
  * Revert "drm/i915: Periodically flush the active lists and requests"
  * Revert "drm/i915/evict: Ensure we completely cleanup on failure"
  * Revert "drm/i915: Maintain LRU order of inactive objects upon access by
    CPU (v2)"
  * Revert "drm/i915: Implement fair lru eviction across both rings. (v2)"
  * Revert "drm/i915: Move the eviction logic to its own file."
  * Revert "drm/i915: prepare for fair lru eviction"

linux (2.6.32-34.76) lucid-proposed; urgency=low

  [Steve Conklin]

  * Release Tracking Bug
    - LP: #836914

  [ Upstream Kernel Changes ]

  * Revert "drm/nv50-nvc0: work around an evo channel hang that some people
    see"
  * Revert "eCryptfs: Handle failed metadata read in lookup"
  * Revert "tunnels: fix netns vs proto registration ordering"

linux (2.6.32-34.75) lucid-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #832332

  [ Upstream Kernel Changes ]

  * drm/i915: Remove BUG_ON from i915_gem_evict_something
    - LP: #828550

linux (2.6.32-34.74) lucid-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #828375

  [ Upstream Kernel Changes ]

  * proc: fix oops on invalid /proc/<pid>/maps access, CVE-2011-1020
    - LP: #813026
    - CVE-2011-1020

linux (2.6.32-34.73) lucid-proposed; urgency=low

  [Herton R. Krzesinski]

  * Release Tracking Bug
    - LP: #824148

  [ Tim Gardner ]

  * SAUCE: rtl8192se: Force a build for a 2.6/3.0 kernel
    - LP: #805494
  * [Config] Add enic/fnic to udebs
    - LP: #801610

  [ Upstream Kernel Changes ]

  * tty: icount changeover for other main devices, CVE-2010-4076,
    CVE-2010-4077
    - LP: #720189
    - CVE-2010-4077
  * fs/partitions/efi.c: corrupted GUID partition tables can cause kernel
    oops
    - LP: #795418
    - CVE-2011-1577
  * ftrace: Only update the function code on write to filter files
    - LP: #802383
  * kmemleak: Do not return a pointer to an object that kmemleak did not
    get
    - LP: #802383
  * CPU hotplug, re-create sysfs directory and symlinks
    - LP: #802383
  * Fix memory leak in cpufreq_stat
    - LP: #802383
  * powerpc/kexec: Fix memory corruption from unallocated slaves
    - LP: #802383
  * powerpc/oprofile: Handle events that raise an exception without
    overflowing
    - LP: #802383
  * mtd: mtdconcat: fix NAND OOB write
    - LP: #802383
  * x86, 64-bit: Fix copy_[to/from]_user() checks for the userspace address
    limit
    - LP: #802383
  * ext3: Fix fs corruption when make_indexed_dir() fails
    - LP: #802383
  * jbd: Fix forever sleeping process in do_get_write_access()
    - LP: #802383
  * jbd: fix fsync() tid wraparound bug
    - LP: #802383
  * ext4: release page cache in ext4_mb_load_buddy error path
    - LP: #802383
  * Fix Ultrastor asm snippet
    - LP: #802383
  * x86, amd: Do not enable ARAT feature on AMD processors below family
    0x12
    - LP: #802383
  * x86, ...

[Pacho-gentoo (pacho-gentoo)]

This is probably obsolete now after so many years :/

[Pacho-gentoo (pacho-gentoo)]

Please test with an updated system