Bug 507122

I'd say it's likely the same bug as nv #484738 you're experiencing.  I'd be interested in knowing if this happens with KMS (add nouveau.modeset=1 to your boot options) enabled, it handles the hw cursor slightly differently to nv and nouveau's userspace modesetting.

This is in no way related to #495534, the symptoms are the same (the display engine hanging), but that can be caused by many, many things.

I added that to my grub.conf - I'll update this bug if I encounter it again. The once-a-week-ish occurence makes it hard to know if this squashes it quickly.

Cool, thanks!  I'll leave the NEEDINFO flag set until you update :)

No further crashes have occurred. I'm not sure if/how this fix should be rolled into mainstream or just left as an option people must discover and apply if they see the problem.

Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command

yum upgrade --enablerepo='*-updates-testing'

Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD .

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

Pat, have you had any other occurrences of this bug since the original report?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[Note please, that this is machine generated comment for large amount of bugs; due to some technical issues, it is possible we've missed some of the responses -- it is happens, please, just a make a comment about that; that we will see. Thank you]

The problem seems to have disappeared completely. I am reluctant to try it without modeset=1, but I've been sticking with fedora 11. When I hop up to Fedora 13, I'll try it without that parameter - the overhaul of nouveau might be a gamechanger anyhow. I'm closing the bug.

It's ok, as of F13 nouveau doesn't even support nomodeset :)  Thanks for the update.

Just happened again with F13.

[  6094.363] [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[  6094.363]
Backtrace:
[  6094.363] 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x4a9098]
[  6094.363] 1: /usr/bin/Xorg (mieqEnqueue+0x1f4) [0x4a3724]
[  6094.363] 2: /usr/bin/Xorg (xf86PostMotionEventP+0xc4) [0x46df34]
[  6094.363] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7f1296157000+0x3dbf) [0x7f129615adbf]
[  6094.363] 4: /usr/bin/Xorg (0x400000+0x7b9b7) [0x47b9b7]
[  6094.363] 5: /usr/bin/Xorg (0x400000+0x11c5b3) [0x51c5b3]
[  6094.363] 6: /lib64/libc.so.6 (0x3ed5600000+0x32a20) [0x3ed5632a20]
[  6094.363] 7: /lib64/libc.so.6 (ioctl+0x7) [0x3ed56d95a7]
[  6094.363] 8: /usr/lib64/libdrm.so.2 (drmIoctl+0x28) [0x3ee6e03388]
[  6094.363] 9: /usr/lib64/libdrm.so.2 (drmCommandWrite+0x1b) [0x3ee6e0360b]
[  6094.364] 10: /usr/lib64/libdrm_nouveau.so.1 (0x7f1297dd3000+0x2dfd) [0x7f1297dd5dfd]
[  6094.364] 11: /usr/lib64/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xfe) [0x7f1297dd5fee]
[  6094.364] 12: /usr/lib64/libdrm_nouveau.so.1 (0x7f1297dd3000+0x207a) [0x7f1297dd507a]
[  6094.364] 13: /usr/lib64/libdrm_nouveau.so.1 (nouveau_pushbuf_flush+0x190) [0x7f1297dd5450]
[  6094.364] 14: /usr/lib64/xorg/modules/libexa.so (0x7f1297161000+0x9655) [0x7f129716a655]
[  6094.364] 15: /usr/lib64/xorg/modules/libexa.so (0x7f1297161000+0xa1fa) [0x7f129716b1fa]
[  6094.364] 16: /usr/bin/Xorg (0x400000+0xdc6db) [0x4dc6db]
[  6094.364] 17: /usr/lib64/xorg/modules/libexa.so (0x7f1297161000+0xb470) [0x7f129716c470]
[  6094.364] 18: /usr/bin/Xorg (0x400000+0xdc0ea) [0x4dc0ea]
[  6094.364] 19: /usr/bin/Xorg (0x400000+0xd260e) [0x4d260e]
[  6094.364] 20: /usr/bin/Xorg (0x400000+0x26dec) [0x426dec]
[  6094.364] 21: /usr/bin/Xorg (0x400000+0x2189a) [0x42189a]
[  6094.364] 22: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x3ed561ec5d]
[  6094.364] 23: /usr/bin/Xorg (0x400000+0x21449) [0x421449]

dmesg says:
[drm] nouveau 0000:01:00.0: PFIFO_DMA_PUSHER - Ch 2

I don't see any similarity between this crash and the one originally reported here.  I think you are now experiencing bug 618143.

Setting this bug back to CLOSED|CURRENTRELEASE



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers