Red Hat Bugzilla – Bug 36917
X server goes into a tight infinite loop
Last modified: 2007-04-18 12:32:45 EDT
XFree86-4.0.3-8 left alone for a while on Athlon machine with a Matrox G400 card machine, running at this moment 2.2.19-7.0.1 kernel, goes into an infinite loop locking an access to screen (blank) keyboard and mouse. It fills, quite fast, /var/log/messages with repeating entries in this style: Apr 20 15:50:24 smok kernel: [drm:mga_lock] *ERROR* Process 870 using kersing kernel context 0 Apr 20 15:50:24 smok kernel: [drm:mga_lock] *ERROR* Process 870 using kernel context 0 Apr 20 15:50:24 smok last message repeated 65 times .... over and over (what is "kersing"??? garbled syslog?). 'top' shows this (and nothing else really active): 3:37pm up 7:04, 5 users, load average: 2.02, 2.02, 1.86 78 processes: 74 sleeping, 4 running, 0 zombie, 0 stopped CPU states: 8.3% user, 91.6% system, 0.0% nice, 0.0% idle Mem: 130592K av, 127976K used, 2616K free, 0K shrd, 11600K buff Swap: 99304K av, 0K used, 99304K free 59120K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 870 root 18 0 39428 38M 2852 R 62.7 30.1 33:13 X 303 root 17 0 608 608 512 R 35.8 0.4 14:29 syslogd ...... ps shows the following processes: USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND ... root 869 0.0 0.9 3252 1244 ? S 08:34 0:00 gdm root 870 9.7 11.3 41924 14772 ? RL 08:34 42:59 \_ /etc/X11/X -auth /var/gdm/:0.Xauth :0 root 871 0.0 1.1 3320 1512 ? S 08:34 0:00 \_ gdm michal 882 0.0 0.0 0 0 ? Z 08:34 0:00 \_ [gnome-session <defunct>] but an attempt to check 'wchan' shows only this: 869 ? root gdm - 140 wait4 870 ? root X - 100 - 871 ? root gdm - 140 do_select Attaching 'strace' to process 870 only shows that it loops very fast on the following system call: 870 ioctl(8, 0x4008642a, 0xbffff2e8) = -1 EINVAL (Invalid argument) 870 ioctl(8, 0x4008642a, 0xbffff2e8) = -1 EINVAL (Invalid argument) ..... Attached gdb gives this: (gdb) where #0 0x40139da4 in __ioctl () from /lib/libc.so.6 #1 0xbffff2e8 in ?? () #2 0x828ad4f in ?? () #3 0x846f215 in ?? () #4 0x869cf4c in ?? () #5 0x846e823 in ?? () #6 0x80b774c in WakeupHandler () #7 0x80d2abc in WaitForSomething () #8 0x80b0ec4 in Dispatch () #9 0x80c20fb in main () #10 0x4007bf31 in __libc_start_main (main=0x80c1b70 <main>, argc=4, ubp_av=0xbffffb04, init=0x806c048 <_init>, fini=0x817d52c <_fini>, rtld_fini=0x4000e274 <_dl_fini>, stack_end=0xbffffafc) at ../sysdeps/generic/libc-start.c:129 Even after killing all X processes (SIGTERM is ineffective and SIGKILL has to be used) a screen remains dark and a machine is useless on a console without reboot. The above _may_ have something to do with a presensce of an active in a time of an incident screensaver daemon. This is repeatable although one has to wait for a while. Michal michal@harddata.com
XFree86 4.0.3 + kernel 2.2.x in any combination is not supported. DRI is tightly linked to 2.4.x. If you disable DRI it should work ok, but again it is not supported - although general bugs are certainly valid reports as long as they can be reproduced in supported configurations. If you need DRI, and want to use 2.2.19, tou'll need to use the DRM that is part of XFree86 instead by enabling the imake BuildXF86DRM option in the spec file and adding whatever extra is needed to build the kernel modules against your custom kernel. What might be easier though is to take the DRM code out of XFree and add it to your kernel build instead. I have no idea how difficult this may be or what problems may result, but I suspect it isn't too difficult. The reason for all of this is that the kernel side DRM in 2.2 and 2.4 is different, and it is not possible to support both at once. Mesa may complicate it further as well. Also your "kersing" syslog entry is a garbled syslog message caused by log messages flooding syslog and maxing out it's 4k or so ring buffer. Harmless but confusing. Hope this helps.
All of this is fine, dandy, and even understandable but some note about it should find a prominent place in release notes and maybe even in a package description displayed by RPM. Various binaries, like 4.0.3-5, released in RH 7.1, are supposed to work across different 7.x releases and in this case they do but with non-obvious, at the first look, limitations. What makes this even more "interesting" is that disabling 'agpgart' in /etc/modules.conf does not, unfortunately, work as X server is loading some modules on its own. Yes, _I_ know how to work around. :-) BTW - accidentally loading without errors (it happens) agpgart and drm modules on Alpha is currently causing an instant death of video on initialization. If you will get errors and rejects things work just fine although without a hardware acceleration. Curious state of affairs, isn't it?