Bug 35360 - nouveau: no space while hiding cursor
Summary: nouveau: no space while hiding cursor
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: Other Linux (All)
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-16 09:00 UTC by Lucas Stach
Modified: 2011-05-11 11:47 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Nomiinal Xor.0.log while message persists regular output in dmesg (31.60 KB, text/plain)
2011-03-22 10:21 UTC, Robert White
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lucas Stach 2011-03-16 09:00:57 UTC
After some time with moderate to high system load I get this message:

[163104.714192] [drm] nouveau 0000:01:00.0: no space while hiding cursor

This is a dualhead setup and I get one of those messages ever when my cursor goes from one screen to the other. Concomitant I sometimes see a stuck phantom cursor on the "inactive" screen.

It seems this message spewing begins after this fault:
[96771.217938] [drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 2 Get 0x002004e150 Put 0x002004e554 IbGet 0x00000925 IbPut 0x00000940 State 0x8000a684 (err: INVALID_CMD) Push 0x00400040
[96771.227999] [drm] nouveau 0000:01:00.0: PGRAPH - DATA_ERROR BEGIN_END_ACTIVE
[96771.228001] [drm] nouveau 0000:01:00.0: PGRAPH - DATA_ERROR
[96771.228001] [drm] nouveau 0000:01:00.0: PGRAPH - ch 2 (0x0000a38000) subc 5 class 0x8397 mthd 0x1360 data 0x00000000
[96771.228001] [drm] nouveau 0000:01:00.0: PGRAPH - DATA_ERROR BEGIN_END_ACTIVE
[96771.228001] [drm] nouveau 0000:01:00.0: PGRAPH - DATA_ERROR
[96771.228001] [drm] nouveau 0000:01:00.0: PGRAPH - ch 2 (0x0000a38000) subc 5 class 0x8397 mthd 0x155c data 0x00000000
[96771.228001] [drm] nouveau 0000:01:00.0: PGRAPH - DATA_ERROR BEGIN_END_ACTIVE
[96771.228001] [drm] nouveau 0000:01:00.0: PGRAPH - DATA_ERROR
[96771.228001] [drm] nouveau 0000:01:00.0: PGRAPH - ch 2 (0x0000a38000) subc 5 class 0x8397 mthd 0x1560 data 0x20053000
[96771.228001] [drm] nouveau 0000:01:00.0: PGRAPH - DATA_ERROR BEGIN_END_ACTIVE
[96771.228001] [drm] nouveau 0000:01:00.0: PGRAPH - DATA_ERROR
[96771.228001] [drm] nouveau 0000:01:00.0: PGRAPH - ch 2 (0x0000a38000) subc 5 class 0x8397 mthd 0x1564 data 0x00000000
[103270.749001] [drm] nouveau 0000:01:00.0: EvoCh 0 Mthd 0x0000 Data 0x00000400 (0x0002 0x01)

Graphics stack is:
nouveau kernel from git (7972f91c24bb66643d76cf635faea78eb184e6b6)
libdrm from git (3b04c73650b5e9bbcb602fdb8cea0b16ad82d0c0)
xorg-x11-server-Xorg-1.9.4-1.fc14
xf-video-nouveau from git (ace98a492353e6de712f4f717e6d3f562e3591f0)

Graphics adapter is a nva0.
Comment 1 Robert White 2011-03-22 10:21:21 UTC
Created attachment 44717 [details]
Nomiinal Xor.0.log while message persists regular output in dmesg
Comment 2 Robert White 2011-03-22 10:22:17 UTC
I have started getting this as well.

This is a single-headed laptop running 64bit system running linux-2.6.38-gentoo kernel compiled with gcc 4.5.2 p1.1. [there are four outputs available I think but only one is connected.]

All components are from the gentoo x11 overlay (so they are fresh fetches from the git tree as of my last rebuild several days ago). I am not sure how to get the git signatures.

I am using gallium and i have disabled classic (since it wouldnt' compile as some files were missing form the git commit.)

My system has been up for a day, and the screen has been going blank and back (normally, e.g. blank screen saver) while there is full-blown KDE 4.6 running and a VMWare instance running in non-unity mode.

I was going to git fetch and rebuild but I figured that since the system is still running fine despite the message i could sit on the configuration for a while in case there is something I can collect for the devs...?

There are _no_ corresponding messages in Xorg.0.log. It's last message was the final messages of a normal startup, which in my case was

[  3747.106] (--) SynPS/2 Synaptics TouchPad: touchpad found

and that was quite a long time ago.

Uptime: 10:04:01 up 1 day,  6:05, 11 users,  load average: 0.25, 0.24, 0.19

[107527.262456] [drm] nouveau 0000:01:00.0: no space while hiding cursor
[107542.332665] [drm] nouveau 0000:01:00.0: no space while hiding cursor
[107671.592721] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP_TPDMA - VM: Trapped write at 0041ef9d00 status 0000cb20 channel 2 (0x00000ce0)
[107671.592729] [drm] nouveau 0000:01:00.0: PGRAPH_TRAP_TPDMA_2D - TP 0 - Unknown fault at address 0041ef9d00
[107671.592736] [drm] nouveau 0000:01:00.0: PGRAPH_TRAP_TPDMA_2D - TP 0 - e0c: 00000000, e18: 00000000, e1c: 01740000, e20: 00000011, e24: 0c030000
[107671.592743] [drm] nouveau 0000:01:00.0: PGRAPH - TRAP
[107671.592752] [drm] nouveau 0000:01:00.0: PGRAPH - ch 2 (0x0000ce0000) subc 2 class 0x502d mthd 0x0860 data 0x72727272
[107701.958991] [drm] nouveau 0000:01:00.0: no space while hiding cursor
[107718.031554] [drm] nouveau 0000:01:00.0: no space while hiding cursor

My system tempratures are all nominal (not that it matters)
Comment 3 Robert White 2011-03-22 10:32:03 UTC
Bonus Symptom: If I try to switch to VT(1) [e.g. ctrl-alt-f1] the cursor disappears but the screen doesn't switch. Keyboard input goes nowhere, but when I "switch back" [ctrl-alt-f7] the cursor returns and the keyboard comes back to life. Any attempt to go from VT1-non-func to VT2-non-func makes no differenc.

DMESG from two attmpts left this behind...

[109438.348916] [drm] nouveau 0000:01:00.0: no space while hiding cursor
[109440.616640] detected fb_set_par error, error code: -16
[109456.000523] [drm] nouveau 0000:01:00.0: no space while hiding cursor
[109456.796429] detected fb_set_par error, error code: -16
[109473.865107] [drm] nouveau 0000:01:00.0: no space while hiding cursor


Note that the input paths in the alternate VTs are still good as I could blindly log in before switching back. from /var/log/messages:

Mar 22 10:27:39 BAEatBoeing login[18516]: ROOT LOGIN  on '/dev/tty5'

Another possible contributor is that I have 'transparent hugepage' support active. I don't know it that could have glombed onto some mapping as I no idea how it really works 8-). I do know that the xorg shared mapping pages "seem to" count since the number of hugepage mappings was non-zero immediately after xorg started. (weak evidence, I know...)
Comment 4 Lucas Stach 2011-05-11 11:47:10 UTC
Fixed by xf86-video-nouveau commit 8378443bd3b26b57ef2ae424a700e01ead813d33.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.