| Summary: | app-editors/emacs-23.1-r3 freezes X (nvidia driver) with KDE-4.4.4 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | quazgar <quazgar> |
| Component: | [OLD] KDE | Assignee: | Doug Goldstein (RETIRED) <cardoe> |
| Status: | RESOLVED TEST-REQUEST | ||
| Severity: | critical | CC: | emacs, x11 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | Photo of emacs' scratch buffer | ||
|
Description
quazgar
2010-07-18 12:56:17 UTC
It's possibly at least partly a bug in the nvidia driver (or the nvidia driver gets fed bogus data), as can be seen from these lines from Xorg.0.log correlated with the problem: (WW) Jul 18 15:41:44 NVIDIA(0): The NVIDIA X driver has encountered too many errors. Falling (WW) Jul 18 15:41:44 NVIDIA(0): back to legacy PCI mode. Some camera shots of emacs before failing will follow. Created attachment 239249 [details]
Photo of emacs' scratch buffer
This image shows a garbled emacs window. It seems as if the characters' background would access the same memory as use by KDE's panel (notice the program icons clearly visible there). I find it hard to guess if this is a cause for X freezing or maybe "just" another bug. Also I don't know if this is the fault of the Nvidia driver, KDE (maybe plasma), QT, GTK (emacs was compiled with +gtk) or emacs itself.
Could you please try with Emacs 23 and if this goes with no success with the emacs-vcs-24* ebuild? (In reply to comment #3) > Could you please try with Emacs 23 Which minor version of 23 did you mean? I have 23.1-r3 installed here. > and if this goes with no success with the > emacs-vcs-24* ebuild? Tried it and I can't reproduce any of the errors with that version (yet). Is there any estimate how long 24 will take for the next stable release (a matter of few/many months/years)? I'll also do more testing with emacs-vcs-24 and try to use Emacs 23 compiled without the gtk use flag. (In reply to comment #4) > (In reply to comment #3) > > Could you please try with Emacs 23 > Which minor version of 23 did you mean? I have 23.1-r3 installed here. 23.2 was intended. > > and if this goes with no success with the > > emacs-vcs-24* ebuild? > Tried it and I can't reproduce any of the errors with that version (yet). Is > there any estimate how long 24 will take for the next stable release (a matter > of few/many months/years)? No estimate here. But it will be longer. What you can do though is run the 24 version and select it as your active main version with eselect-emacs. > I'll also do more testing with emacs-vcs-24 and try to use Emacs 23 compiled > without the gtk use flag. That may be a good idea. Some more tests and two freezes later (Alt-SysRq-... still works, fortunately) it seems that 23.2 does not help, turning off KDE compositing may be helpful, but I'll test it more. Since this bug is not always reproducible, I cannot say I'm 100% sure it can not happen with the 24 vcs version. One more thing: Even after killing X and restarting /etc/init.d/xdm, some areas of the display are still garbled, looks like some deeper memory corruption to me. This is extremely hard to debug as it can happen anywhere in the graphics driver, toolkit or the application itself. Do you have a garbled screen if you disable the gtk USE flag and build with motif (yes, I know it is ugly)? (In reply to comment #7) > Do you have a garbled screen if you > disable the gtk USE flag and build with motif (yes, I know it is ugly)? The complete freeze also happens with motif instead of gtk, at least with desktop compositing enabled. I'll try it without compositing the next days, maybe that will allow some conclusions. Actually it seems as if the last time, there was a "regular" X crash, unless the following messages in Xorg.1.log.old come from shutting down the machine with the Magic SysReq keys: ... [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/X (xorg_backtrace+0x28) [0x49e758] 1: /usr/bin/X (mieqEnqueue+0x203) [0x49e133] 2: /usr/bin/X (xf86PostKeyEventP+0x66) [0x479276] 3: /usr/bin/X (xf86PostKeyboardEvent+0x19) [0x4792f9] 4: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7fbbee6d8000+0x40d7) [0x7fbbee6dc0d7] 5: /usr/bin/X (0x400000+0x6ced7) [0x46ced7] 6: /usr/bin/X (0x400000+0x114c36) [0x514c36] 7: /lib/libpthread.so.0 (0x7fbbf371f000+0xf010) [0x7fbbf372e010] 8: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0x77e42) [0x7fbbef497e42] 9: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0xb02b9) [0x7fbbef4d02b9] 10: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0xb0656) [0x7fbbef4d0656] 11: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (_nv002733X+0x9d) [0x7fbbef4d0c7d] 12: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (_nv001056X+0x19e) [0x7fbbef498c8e] 13: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0xdadf6) [0x7fbbef4fadf6] 14: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0xdaa22) [0x7fbbef4faa22] 15: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0x33cfce) [0x7fbbef75cfce] 16: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0x340db3) [0x7fbbef760db3] 17: /usr/bin/X (0x400000+0xd413c) [0x4d413c] 18: /usr/lib64/xorg/modules/extensions/libextmod.so (0x7fbbf2122000+0xc815) [0x7fbbf212e815] 19: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0x2fde57) [0x7fbbef71de57] 20: /usr/bin/X (miGlyphs+0x5e6) [0x55e6e6] 21: /usr/lib64/xorg/modules/drivers/nvidia_drv.so (0x7fbbef420000+0x332473) [0x7fbbef752473] 22: /usr/bin/X (0x400000+0xd1675) [0x4d1675] 23: /usr/bin/X (0x400000+0xcbaa6) [0x4cbaa6] 24: /usr/bin/X (0x400000+0x2f634) [0x42f634] 25: /usr/bin/X (0x400000+0x2508b) [0x42508b] 26: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fbbf2571bbd] 27: /usr/bin/X (0x400000+0x24c39) [0x424c39] It's probably better if the x11 and nvidia people have a look at this bug then. I assume newer versions have resulted in this working since there's been no further news. |
