Bug 36917 - X server goes into a tight infinite loop
X server goes into a tight infinite loop
Status: CLOSED WONTFIX
Product: Red Hat Raw Hide
Classification: Retired
Component: XFree86 (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-04-20 18:37 EDT by Michal Jaegermann
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-20 18:37:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2001-04-20 18:37:48 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
Comment 1 Mike A. Harris 2001-04-20 19:26:49 EDT
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.
Comment 2 Michal Jaegermann 2001-04-21 15:49:24 EDT
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?

Note You need to log in before you can comment on or make changes to this bug.