mouse usage causes Xorg CPU usage to spike, and mouse pointer becomes less responsive
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Invalid
|
High
|
Unassigned | ||
Lucid |
Invalid
|
High
|
Unassigned | ||
xserver-xorg-video-nouveau (Fedora) |
Won't Fix
|
Medium
|
Bug Description
Binary package hint: xorg
Over time, my mouse pointer becomes more and more erratic and unresponsive. It never becomes unusable, but it gets jerky and hard to use. If I run 'top', I can watch Xorg CPU usage spike in direct correlation to how much I move the mouse around (and the mouse performance gets worse while I'm doing this). If I wave the mouse pointer around a lot, CPU will reliably hit 100%, and the pointer will be far behind my physical gestures with the mouse (and will continue to move for a while after I stop moving the mouse). CPU climbs back down after I stop moving the mouse.
When I first log in, everything is fine. This problem gets worse the longer I stay in the same X Session. I haven't tried logging out back to GDM and logging back in; if you need me to I can try that.
Switching between windows / desktops is also increasingly sluggish.
This is all on Ubuntu lucid (development branch).
I don't know if this is related to any of these bugs:
ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: xorg 1:7.5+3ubuntu1
ProcVersionSign
Uname: Linux 2.6.32-19-generic i686
NonfreeKernelMo
Architecture: i386
CheckboxSubmission: 5e7a695a9deba63
CheckboxSystem: d00f84de8a55581
Date: Thu Apr 8 15:08:28 2010
DkmsStatus:
bcmwl, 5.60.48.36+bdcom, 2.6.31-20-generic, i686: installed
bcmwl, 5.60.48.36+bdcom, 2.6.32-19-generic, i686: installed
bcmwl, 5.60.48.36+bdcom, 2.6.32-17-generic, i686: installed
bcmwl, 5.60.48.36+bdcom, 2.6.32-18-generic, i686: installed
MachineType: Dell Inc. XPS M1330
ProcCmdLine: root=UUID=
ProcEnviron:
PATH=(custom, user)
LANG=en_US.utf8
SHELL=/bin/bash
SourcePackage: xorg
Symptom: display
dmi.bios.date: 11/19/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A14
dmi.board.name: 0U8042
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.
dmi.product.name: XPS M1330
dmi.sys.vendor: Dell Inc.
system:
distro: Ubuntu
codename: lucid
architecture: i686
kernel: 2.6.32-19-generic
[lspci]
00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 0c)
Subsystem: Dell Device [1028:0209]
01:00.0 VGA compatible controller [0300]: nVidia Corporation G86 [GeForce 8400M GS] [10de:0427] (rev a1)
Subsystem: Dell Device [1028:0209]
In Red Hat Bugzilla #537065, Gianluca (gianluca-redhat-bugs) wrote : | #61 |
In Red Hat Bugzilla #537065, Ben (ben-redhat-bugs) wrote : | #62 |
Is this 100% reproducible on your system, or a random occurance?
In Red Hat Bugzilla #537065, Gianluca (gianluca-redhat-bugs) wrote : | #63 |
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.
In Red Hat Bugzilla #537065, Richard (richard-redhat-bugs) wrote : | #64 |
I have experienced this same problem on my desktop system a few days ago. I have not used suspend/resume.
xorg-x11-
xorg-x11-
xorg-x11-
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...
In Red Hat Bugzilla #537065, Richard (richard-redhat-bugs) wrote : | #65 |
Created attachment 369809
Xorg.0.log from the session where the cursor problem occured
In Red Hat Bugzilla #537065, Richard (richard-redhat-bugs) wrote : | #66 |
Created attachment 369810
Relevant /var/log/messages from the session where the cursor problem occured
In Red Hat Bugzilla #537065, Andrew (andrew-redhat-bugs) wrote : | #67 |
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-
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.
In Red Hat Bugzilla #537065, Andrew (andrew-redhat-bugs) wrote : | #68 |
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.
In Red Hat Bugzilla #537065, Tom (tom-redhat-bugs) wrote : | #69 |
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.
In Red Hat Bugzilla #537065, Gianluca (gianluca-redhat-bugs) wrote : | #70 |
Tom, which graphic card are you running (use "lspci -nn" to find out)?
In Red Hat Bugzilla #537065, Tom (tom-redhat-bugs) wrote : | #71 |
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.
In Red Hat Bugzilla #537065, Robert (robert-redhat-bugs-1) wrote : | #72 |
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
In Red Hat Bugzilla #537065, Ben (ben-redhat-bugs) wrote : | #73 |
*** Bug 541628 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #537065, Ben (ben-redhat-bugs) wrote : | #74 |
*** Bug 548545 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #537065, Kyle (kyle-redhat-bugs) wrote : | #75 |
I'm seeing similar symptoms.
02:00.0 VGA compatible controller [0300]: nVidia Corporation GT200 [GeForce GTX 260] [10de:05e2] (rev a1)
xorg-x11-
kernel-
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).
In Red Hat Bugzilla #537065, Ben (ben-redhat-bugs) wrote : | #76 |
Are you guys able to update to kernel-
In Red Hat Bugzilla #537065, Tom (tom-redhat-bugs) wrote : | #77 |
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.
In Red Hat Bugzilla #537065, Gianluca (gianluca-redhat-bugs) wrote : | #78 |
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!
In Red Hat Bugzilla #537065, Gianluca (gianluca-redhat-bugs) wrote : | #79 |
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.
In Red Hat Bugzilla #537065, Robert (robert-redhat-bugs-1) wrote : | #80 |
Yup, I've re-tested and this issue seems fixed for me too.
In Red Hat Bugzilla #537065, Miroslav (miroslav-redhat-bugs) wrote : | #81 |
Experiencing this issue right on Quadro NVS 140m (Thinkpad T61) - dual screen setup with
kernel-
xorg-x11-
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
In Red Hat Bugzilla #537065, Ben (ben-redhat-bugs) wrote : | #82 |
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).
In Red Hat Bugzilla #537065, Miroslav (miroslav-redhat-bugs) wrote : | #83 |
Ben, it isn't easily reproducible :/. My system was running for several days with kernel-
In Red Hat Bugzilla #537065, Ben (ben-redhat-bugs) wrote : | #84 |
*** Bug 562496 has been marked as a duplicate of this bug. ***
In Red Hat Bugzilla #537065, Laurence (laurence-redhat-bugs) wrote : | #85 |
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/
+++ b/drivers/
@@ -41,6 +41,14 @@ nv50_cursor_
update) struct drm_device *dev = nv_crtc->base.dev;
int ret;
+ static int count = 0;
+
+ if (count > 3) {
+ return;
+ } else {
+ count++;
+ }
+
if (update && nv_crtc-
@@ -76,6 +84,8 @@ nv50_cursor_
update) struct drm_device *dev = nv_crtc->base.dev;
int ret;
+ return;
+
if (update && !nv_crtc-
-------
This raises a lot of issues - what was happening is that READ_GET() in
drivers/
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/
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.
In Red Hat Bugzilla #537065, Ben (ben-redhat-bugs) wrote : | #86 |
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.
In Red Hat Bugzilla #537065, Stefan (stefan-redhat-bugs) wrote : | #87 |
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-
xorg-x11-
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.
In Red Hat Bugzilla #537065, Stefan (stefan-redhat-bugs) wrote : | #88 |
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.
In Red Hat Bugzilla #537065, Stefan (stefan-redhat-bugs) wrote : | #89 |
Sorry for spamming, but the only messages I get are "no space while hiding cursor", no unhiding or setting cursor image.
In Red Hat Bugzilla #537065, Stefan (stefan-redhat-bugs) wrote : | #90 |
One more thing - it doesn't have to do with Firefox/
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.
In Red Hat Bugzilla #537065, Stefan (stefan-redhat-bugs) wrote : | #91 |
Created attachment 402070
log excerpt
It happened again today with the same kernel and nouveau versions still. And xorg-x11-
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.
In Red Hat Bugzilla #537065, Stefan (stefan-redhat-bugs) wrote : | #92 |
Created attachment 402071
xorg server log
In Red Hat Bugzilla #537065, Gianluca (gianluca-redhat-bugs) wrote : | #93 |
Ben, I'm sorry to say this issue is showing itself again, I'm now running the latest F12 bits, kernel-
I'm probably going to move on F13 soon so I will be able to say if the same happens there.
In Red Hat Bugzilla #537065, Gianluca (gianluca-redhat-bugs) wrote : | #94 |
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
Karl Fogel (kfogel) wrote : | #1 |
- BootDmesg.txt Edit (54.6 KiB, text/plain; charset="utf-8")
- CurrentDmesg.txt Edit (123.1 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (4.5 KiB, text/plain; charset="utf-8")
- GdmLog.gz Edit (4.8 KiB, application/x-gzip)
- GdmLog1.gz Edit (5.0 KiB, application/x-gzip)
- GdmLog2.gz Edit (4.6 KiB, application/x-gzip)
- Lspci.txt Edit (15.9 KiB, text/plain; charset="utf-8")
- Lsusb.txt Edit (803 bytes, text/plain; charset="utf-8")
- PciDisplay.txt Edit (817 bytes, text/plain; charset="utf-8")
- ProcCpuinfo.txt Edit (1.5 KiB, text/plain; charset="utf-8")
- ProcInterrupts.txt Edit (1.6 KiB, text/plain; charset="utf-8")
- ProcModules.txt Edit (2.7 KiB, text/plain; charset="utf-8")
- RelatedPackageVersions.txt Edit (231 bytes, text/plain; charset="utf-8")
- UdevDb.txt Edit (122.0 KiB, text/plain; charset="utf-8")
- UdevLog.txt Edit (271.7 KiB, text/plain; charset="utf-8")
- XorgConf.txt Edit (1.1 KiB, text/plain; charset="utf-8")
- XorgLog.gz Edit (5.6 KiB, application/x-gzip)
- XorgLogOld.gz Edit (5.8 KiB, application/x-gzip)
- Xrandr.txt Edit (6.7 KiB, text/plain; charset="utf-8")
- glxinfo.txt Edit (18.7 KiB, text/plain; charset="utf-8")
- monitors.xml.txt Edit (1.6 KiB, text/plain; charset="utf-8")
- setxkbmap.txt Edit (233 bytes, text/plain; charset="utf-8")
- xdpyinfo.txt Edit (17.3 KiB, text/plain; charset="utf-8")
- xkbcomp.txt Edit (44.2 KiB, text/plain; charset="utf-8")
Bryce Harrington (bryce) wrote : | #2 |
RAOF - Karl is one of the Canonical launchpad developers, mind helping him with this bug?
affects: | xorg (Ubuntu) → xserver-xorg-video-nouveau (Ubuntu) |
Changed in xserver-xorg-video-nouveau (Ubuntu): | |
assignee: | nobody → Chris Halse Rogers (raof) |
importance: | Undecided → High |
milestone: | none → ubuntu-10.04 |
status: | New → Triaged |
Bryce Harrington (bryce) wrote : | #3 |
This error in dmesg appears pertinent:
[101728.482742] [drm] nouveau 0000:01:00.0: no space while unhiding cursor
description: | updated |
Bryce Harrington (bryce) wrote : | #4 |
From the glxinfo it seems you don't have hw acceleration, which can cause performance problems and cpu loads (since rendering is done in sw). Make sure desktop effects is not enabled (it shouldn't even be possible to enable them). Also, check if you are running any 3D programs or anything which uses compositing.
OpenGL renderer string: Software Rasterizer
Bryce Harrington (bryce) wrote : | #5 |
Looks like this and lp #542929 are dupes although symptoms are slightly different.
Bryce Harrington (bryce) wrote : | #6 |
Well, maybe not dupes, but they both have the same errors in dmesg. Might be related.
Karl Fogel (kfogel) wrote : | #7 |
Thanks for all the help, Bryce. No desktop effects enabled, AFAIK, and no 3D graphics either (I mostly live in Emacs and Firefox).
FWIW, I was using an external monitor setup then (mirrored screens, w/ laptop screen and one external screen). Now I'm using just the laptop screen, after rebooting. So far, the bug has not come back. If it does, I'll leave a note here.
Chris Halse Rogers (raof) wrote : | #8 |
I suspect that adding an xorg.conf with
Section "Device"
Driver "nouveau"
Identifier "nouveau"
Option "HWCursor" "false"
EndSection
will resolve this for you by just not using the hardware cursor. Does that fix it?
Changed in xserver-xorg-video-nouveau (Ubuntu Lucid): | |
status: | Triaged → Incomplete |
Chris Halse Rogers (raof) wrote : | #9 |
Hm. Following the cryptic references in the RH bug, it's possible that there's a kernel commit that would fix this:
commit 1cfa49c2f1f3f42
Author: Ben Skeggs <email address hidden>
Date: Tue Feb 9 16:59:26 2010 +1000
drm/nv50: EVO uses a real ring buffer, not jumps back to start like PFIFO
Tested on NV84GL and NV96 with cursor state caching disabled to force
lots of EVO use, no problems seen.
There's been some reports of EVO randomly dying and reporting an error
during cursor state changes for some people, I've been unable to
reproduce on my hardware but hopefully this is the culprit.
Signed-off-by: Ben Skeggs <email address hidden>
I thought we had that in our tree, but it seems that we don't.
affects: | xserver-xorg-video-nouveau (Ubuntu Lucid) → linux (Ubuntu Lucid) |
Changed in linux (Ubuntu Lucid): | |
assignee: | Chris Halse Rogers (raof) → nobody |
Andy Whitcroft (apw) wrote : | #10 |
I have pulled this patch back to Lucid and have build kernels for testing. If those of you who are seeing this issue could test these kernels and report back here that would be helpful. Kernels are at the URL below:
http://
Thanks.
Changed in linux (Ubuntu Lucid): | |
milestone: | ubuntu-10.04 → lucid-updates |
Karl Fogel (kfogel) wrote : | #11 |
Chris, Andy, et al,
Sorry for the late response. It turns out I only see this issue when configured with dual monitors, and (for logistical reasons) I haven't been able to set things up that way the last few days. Would you like me to test this with the new kernel before the end of this week? (I assume I install the kernel with 'dpkg' and it Just Works after reboot? I've built kernels from source... years and years ago :-) ... but never actually installed one from a .deb.)
I will be away from my external monitor on Wednesday, unfortunately, but I could do the testing Thursday...
Michael Orlitzky (michael-orlitzky) wrote : | #12 |
Here are two videos demonstrating the problem, both with and without that last kernel patch. It's the same 64-bit KVM image in both videos, using the latest packages from the repos.
In the first video, I 'cat' the KVM script I'm using. I'm not terribly attached to the disk image if it would be useful for testing.
1. http://
2. http://
Karl Fogel (kfogel) wrote : | #13 |
Michael,
So you're saying it still reproduces for you even with Andy's new kernels?
Michael Orlitzky (michael-orlitzky) wrote : | #14 |
Yes, and in my case, it's most certainly not a nouveau problem.
In Red Hat Bugzilla #537065, Ben (ben-redhat-bugs) wrote : | #95 |
*** Bug 593695 has been marked as a duplicate of this bug. ***
tags: | added: kernel-input kernel-reviewed |
In Red Hat Bugzilla #537065, Jerry (jerry-redhat-bugs) wrote : | #96 |
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/
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-
mesa-dri-
xorg-x11-
xorg-x11-
Is this really the same bug?
Vishal Telangre (vishaltelangre) wrote : | #15 |
My friend also had faced the problem of stucking or freezing of keyboard and mouse after login as he did the upgrade to 10.04 from 9.10! But we found that that was 'cause of his devices such as mouse and keyboard wasn't added in the file /usr/lib/
All step-by-step instructions regarding this "mouse/keyboard stucking issue" are available at link given below:
http://
Thanks (cc Chinmay Inamdar)
Changed in linux (Ubuntu Lucid): | |
status: | Incomplete → Fix Committed |
TylerMD (manuelmorales) wrote : | #16 |
Does any of you have easystroke running. I'm starting to think that that might be the cause.
Michael Orlitzky (michael-orlitzky) wrote : | #17 |
This is a clean install, not an upgrade. And the mouse works, it just causes the CPU usage to go crazy. I don't even have an xorg.conf (a configuration which works fine in a fresh install of, well, anything else).
Not running easystroke either.
And most importantly, it ain't fixed.
Jeremy Foshee (jeremyfoshee) wrote : | #18 |
Vishal Telangre,
Please do not change the state of bugs without explanation, especially those bugs of a serious nature like this. Doing so could potentially cause a bug to be overlooked inadvertently. Marked back to triaged.
Thanks!
~JFo
Changed in linux (Ubuntu Lucid): | |
status: | Fix Committed → Triaged |
Changed in linux (Ubuntu): | |
status: | Incomplete → Triaged |
In Red Hat Bugzilla #537065, David (david-redhat-bugs) wrote : | #97 |
Something similar seems to have recurred in F-13
[drm] nouveau 0000:01:00.0: EvoCh 0 Mthd 0x0000 Data 0x00000400 (0x0002 0x01)
devender (devender-gollapally) wrote : | #19 |
jammen33 (jammen) wrote : | #20 |
@devender, thanks that fixed it me.
before xorg was idling at about 90%, but now it idles around 10%.
jammen33 (jammen) wrote : | #21 |
ok my bad for posting so soon... after a few days xorg is spiking again.
Phurter (johnmckinzie) wrote : | #22 |
@jammen33, same thing here. The fix worked for a day and now the bug is back. My computer is getting down right unusable at times.
Daniel Holm (danielholm) wrote : | #23 |
This drives my crazy. xorg spikes almost all the time! And the nvidia-driver fix att comment #19 didn't do anything to it.
In Red Hat Bugzilla #537065, David (david-redhat-bugs) wrote : | #98 |
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-
xorg-x11-
xorg-x11-
nVidia Corporation G84M [Quadro NVS 140M] (rev a1)
In Red Hat Bugzilla #537065, Donald (donald-redhat-bugs) wrote : | #99 |
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.
In Red Hat Bugzilla #537065, Andrew (andrew-redhat-bugs) wrote : | #100 |
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-
(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-
xorg-x11-
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/
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')
In Red Hat Bugzilla #537065, Andrew (andrew-redhat-bugs) wrote : | #101 |
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-
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
In Red Hat Bugzilla #537065, Andrew (andrew-redhat-bugs) wrote : | #102 |
Also now had the same problem occur with the older RPM:
xorg-x11-
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_
/var/log/messages:
Jul 30 12:34:08 ... kernel: [drm] nouveau 0000:01:00.0: nouveau_
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)
Dragos Vingarzan (vingarzan) wrote : | #24 |
same here... got 11xAsus EeeBox 1012U doing this nasty thing, all the same. I tried many drivers, possible fixes like #19 and nothing - I don't think this is a driver problem. But the strange thing is that I also have 5xAsus EeePC 1201N which I think have the same Atom/ION combination, yet those are all snappy and nice, even with effects enabled.
The easiest way to replicate it to run top in a terminal and to set the delay low, so it will refresh it often. If I maximize the window on a 1920x1200 display, in some seconds the whole thing freezes.
In Red Hat Bugzilla #537065, David (david-redhat-bugs) wrote : | #103 |
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.
[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_
[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...
In Red Hat Bugzilla #537065, Laurence (laurence-redhat-bugs) wrote : | #104 |
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.
In Red Hat Bugzilla #537065, Steve (steve-redhat-bugs) wrote : | #105 |
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-
happens with 2 hours of a reboot under kernel-
/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.
In Red Hat Bugzilla #537065, Gianluca (gianluca-redhat-bugs) wrote : | #106 |
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.
In Red Hat Bugzilla #537065, Stefan (stefan-redhat-bugs) wrote : | #107 |
Same for me. Has not happened once in a very long time (more than 6 months).
In Red Hat Bugzilla #537065, Andrew (andrew-redhat-bugs) wrote : | #108 |
Still happening every so often on F12
(I swapped the flaky mouse out long ago)
Current nouveau is:
xorg-x11-
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)
In Red Hat Bugzilla #537065, Jerry (jerry-redhat-bugs) wrote : | #109 |
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.
John Clemens (clemej) wrote : | #25 |
I see similar problems on my work machine running an NV50-class (160M?) gpu with nouveau. not sure if this will help, but..
I think there are two bugs here. There is one bug in the nouveau driver and a hardware cursor where the hw cursor engine will eventually stop displaying the cursor, especially with two monitors (as each time you switch monitors it causes this cursor reset, or something). this is indicated by the "no space for cursor" type messages in the kernel log which eventually culminate in a message (from faded memoy) "[drm] EvtChg <blah>...", and after that, the cursor won't show on one of the monitors again until a reboot. .I -occasionally- saw this in Lucid with two monitors (maybe once a month), but with maverick it happened every few hours at least. I switched to a software cursor and stopped using my second monitor.
So, upshot is, you may want to try disabling the hardware cursor and see if you have better luck.
The second is that now, using the software cursor, depending on where on the screen I am, just hovering the mouse over a spot in a gtk app causes cpu usage to spike in Xorg, like it's constantly re-drawing the widget that's under the mouse. Hover the mouse over Xterm window and everything's fine. Open a nautilus window and hover over the sidebar, Xorg jumps to 100% and stays there until you move the mouse off, but if you hover over the file icons or the menu, you're fine. Firefox and Thunderbird also have "sensative areas" of the app which cause cpu usage spikes.
So, either we need to fix the hardware cursor in nouveau, or fix the software cursor cpu usage issues.
In general, nouveau was much more stable under Lucid and under Maverick, at least on my box. I have no such issues at home running the intel or OSS radeon drivers.
In Red Hat Bugzilla #537065, Bug (bug-redhat-bugs) wrote : | #110 |
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://
In Red Hat Bugzilla #537065, Laurence (laurence-redhat-bugs) wrote : | #111 |
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.
In Red Hat Bugzilla #537065, Jóhann (jhann-redhat-bugs) wrote : | #112 |
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.
In Red Hat Bugzilla #537065, Gianluca (gianluca-redhat-bugs) wrote : | #113 |
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
In Red Hat Bugzilla #537065, David (david-redhat-bugs) wrote : | #114 |
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_
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.
In Red Hat Bugzilla #537065, David (david-redhat-bugs) wrote : | #115 |
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.
In Red Hat Bugzilla #537065, Gianluca (gianluca-redhat-bugs) wrote : | #116 |
Reassigning to 13 as suggested by Ben on IRC; that will avoid the auto-close.
In Red Hat Bugzilla #537065, Matthew (matthew-redhat-bugs) wrote : | #117 |
(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.
In Red Hat Bugzilla #537065, David (david-redhat-bugs) wrote : | #118 |
(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
In Red Hat Bugzilla #537065, Laurence (laurence-redhat-bugs) wrote : | #119 |
David, I've been using your patch in comment 53 and it's resolved the issue for me too, thank you very much.
In Red Hat Bugzilla #537065, Costantino (costantino-redhat-bugs) wrote : | #120 |
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.
In Red Hat Bugzilla #537065, Costantino (costantino-redhat-bugs) wrote : | #121 |
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/
In Red Hat Bugzilla #537065, Costantino (costantino-redhat-bugs) wrote : | #122 |
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)
In Red Hat Bugzilla #537065, Matthew (matthew-redhat-bugs) wrote : | #123 |
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)
In Red Hat Bugzilla #537065, Ben (ben-redhat-bugs) wrote : | #124 |
(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.
In Red Hat Bugzilla #537065, Dario (dario-redhat-bugs) wrote : | #125 |
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.
In Red Hat Bugzilla #537065, Matthew (matthew-redhat-bugs) wrote : | #126 |
(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).
In Red Hat Bugzilla #537065, Ben (ben-redhat-bugs) wrote : | #127 |
(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.
In Red Hat Bugzilla #537065, Ben (ben-redhat-bugs) wrote : | #128 |
(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.
In Red Hat Bugzilla #537065, Dario (dario-redhat-bugs) wrote : | #129 |
(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...
In Red Hat Bugzilla #537065, Dario (dario-redhat-bugs) wrote : | #130 |
(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.
In Red Hat Bugzilla #537065, Costantino (costantino-redhat-bugs) wrote : | #131 |
As I already asked, how may I find nv50_display.c to try the patch in comment 53?
In Red Hat Bugzilla #537065, Ben (ben-redhat-bugs) wrote : | #132 |
(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-
John Clemens (clemej) wrote : | #26 |
Ahh, this is the bug I meant.
The Fedora bug for this problem has a patch here: https:/
Please consider applying this patch to the Ubuntu kernel.
In Red Hat Bugzilla #537065, Costantino (costantino-redhat-bugs) wrote : | #133 |
Okay, thanks a lot!
I still have the kernel 2.6.35.
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?
In Red Hat Bugzilla #537065, Costantino (costantino-redhat-bugs) wrote : | #134 |
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.
In Red Hat Bugzilla #537065, Costantino (costantino-redhat-bugs) wrote : | #135 |
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!
In Red Hat Bugzilla #537065, Bug (bug-redhat-bugs) wrote : | #136 |
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://
In Red Hat Bugzilla #537065, Bug (bug-redhat-bugs) wrote : | #137 |
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.
Коренберг Марк (socketpair) wrote : | #27 |
Natty, exactly the same issue.
P.S. Please update "Affects" field in this bug, I can not do that.
psypher (psypher246) wrote : | #28 |
This issue is still persisting in precise pangolin. Is there any work being done on it? I have a dual screen setup. Have not yet tested it with one screen. X process idles at about 5% and spikes to 10-12% when I move the mouse.
tags: | added: apport-collected precise running-unity staging |
psypher (psypher246) wrote : apport information | #29 |
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 1.90-0ubuntu1
Architecture: amd64
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: Intel [HDA Intel], device 0: ALC665 Analog [ALC665 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/
/dev/snd/pcmC0D0p: ruald 2626 F...m pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
Card hw:0 'Intel'/'HDA Intel at 0xf0c00000 irq 57'
Mixer name : 'Realtek ALC665'
Components : 'HDA:10ec0665,
Controls : 22
Simple ctrls : 12
Card1.Amixer.info:
Card hw:1 'NVidia'/'HDA NVidia at 0xcbefc000 irq 17'
Mixer name : 'Nvidia GPU 11 HDMI/DP'
Components : 'HDA:10de0011,
Controls : 20
Simple ctrls : 4
DistroRelease: Ubuntu 12.04
EcryptfsInUse: Yes
HibernationDevice: RESUME=
InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Alpha amd64 (20111129.1)
MachineType: Dell Inc. XPS L701X
Package: linux (not installed)
ProcKernelCmdLine: BOOT_IMAGE=
ProcVersionSign
RelatedPackageV
linux-
linux-
linux-firmware 1.62
StagingDrivers: mei
Tags: precise running-unity staging precise running-unity staging
Uname: Linux 3.2.0-4-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip kvm libvirtd lpadmin plugdev sambashare sudo
dmi.bios.date: 11/29/2010
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A06
dmi.board.vendor: Dell Inc.
dmi.board.version: A06
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.
dmi.modalias: dmi:bvnDellInc.
dmi.product.name: XPS L701X
dmi.product.
dmi.sys.vendor: Dell Inc.
psypher (psypher246) wrote : AcpiTables.txt | #30 |
apport information
psypher (psypher246) wrote : AlsaDevices.txt | #31 |
apport information
psypher (psypher246) wrote : AplayDevices.txt | #32 |
apport information
psypher (psypher246) wrote : BootDmesg.txt | #33 |
apport information
psypher (psypher246) wrote : Card0.Amixer.values.txt | #34 |
apport information
psypher (psypher246) wrote : Card0.Codecs.codec.0.txt | #35 |
apport information
psypher (psypher246) wrote : Card1.Amixer.values.txt | #36 |
apport information
psypher (psypher246) wrote : Card1.Codecs.codec.0.txt | #37 |
apport information
psypher (psypher246) wrote : Card1.Codecs.codec.1.txt | #38 |
apport information
psypher (psypher246) wrote : Card1.Codecs.codec.2.txt | #39 |
apport information
psypher (psypher246) wrote : Card1.Codecs.codec.3.txt | #40 |
apport information
psypher (psypher246) wrote : CurrentDmesg.txt | #41 |
apport information
psypher (psypher246) wrote : IwConfig.txt | #42 |
apport information
psypher (psypher246) wrote : Lspci.txt | #43 |
apport information
psypher (psypher246) wrote : Lsusb.txt | #44 |
apport information
psypher (psypher246) wrote : PciMultimedia.txt | #45 |
apport information
psypher (psypher246) wrote : ProcCpuinfo.txt | #46 |
apport information
psypher (psypher246) wrote : ProcEnviron.txt | #47 |
apport information
psypher (psypher246) wrote : ProcInterrupts.txt | #48 |
apport information
psypher (psypher246) wrote : ProcModules.txt | #49 |
apport information
psypher (psypher246) wrote : PulseSinks.txt | #50 |
apport information
psypher (psypher246) wrote : PulseSources.txt | #51 |
apport information
psypher (psypher246) wrote : RfKill.txt | #52 |
apport information
psypher (psypher246) wrote : UdevDb.txt | #53 |
apport information
psypher (psypher246) wrote : UdevLog.txt | #54 |
apport information
psypher (psypher246) wrote : WifiSyslog.txt | #55 |
apport information
penalvch (penalvch) wrote : | #56 |
Karl Fogel, 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://
If it remains an issue, could you please run the following command in the development release from a Terminal (Applications-
apport-collect -p linux <replace-
Also, could you please test the latest upstream kernel available following https:/
kernel-
kernel-
where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-
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-
If the mainline kernel does not fix this bug, please add the following tags:
kernel-
kernel-
As well, please remove the tag:
needs-upstream-
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.
Changed in linux (Ubuntu): | |
status: | Triaged → Incomplete |
tags: | removed: apport-collected precise running-unity staging |
Karl Fogel (kfogel) wrote : | #57 |
I can't comment reliably on whether it's still an issue or not, as the box where I was reproducing it is no longer running Ubuntu (that machine is vanilla Debian GNU/Linux now, for various reasons unrelated to this bug).
But I suspect that after this much time, the bug is probably fixed for everyone, or we would have heard some noise in this issue in the last couple of years. So, I think it's safe to close. Your call, though.
Best,
-Karl
Mikko Tamminen (mikko-k-tamminen) wrote : | #58 |
I also have this bug. When I rotate my mouse over my web-browser, I can get the cpu usage to spike as high as 40%. When I am not moving the mouse, it shows 1% usage. Rotating the mouse over a terminal window, it jumps to 3-5%.
penalvch (penalvch) wrote : | #59 |
Mikko Tamminen, if you have a bug in Ubuntu, the Ubuntu Kernel team, Ubuntu Bug Control team, and Ubuntu Bug Squad would like you to please file a new report by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux
For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https:/
Ubuntu Kernel Team: https:/
Ubuntu Community: https:/
When opening up the new report, please feel free to subscribe me to it.
Please note, not filing a new report would delay your problem being addressed as quickly as possible.
No need exists to comment here at this time. After reading the above documentation in it's entirety, if you have further questions, you are welcome to redirect them to the appropriate mailing list or forum via http://
Thank you for your understanding.
penalvch (penalvch) wrote : | #60 |
Karl Fogel, this bug report is being closed due to your last comment https:/
Changed in linux (Ubuntu): | |
status: | Incomplete → Invalid |
Changed in linux (Ubuntu Lucid): | |
status: | Triaged → Invalid |
Changed in xserver-xorg-video-nouveau (Fedora): | |
importance: | Unknown → Medium |
status: | Unknown → Won't Fix |
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]