Red Hat Bugzilla – Bug 9617
X session freezes
Last modified: 2008-05-01 11:37:54 EDT
X session freezes, for no apparent reason. Happens most often with lots of
windows open, and when moving a Netscape window. When it does happen,
ld-2.1.2.so appears to be hogging the CPU, and using up a ton of memory.
It appears to happen wether KDE or Gnome are in use, but doesn't seem to
happen if lightwieght WMs, such as FVWM or Afterstep, are used.
Based on that, I believe this is a glibc problem, but it may be X related.
Several people in my local LUG are also experiencing this problem, and I
noticed that it was reported in the January issue of LinuxJournal (pg.88)
That's about the best info I can provide... I'm not a C hacker!
This is the same as bug #9616... I resubmitted it after changing my preferences,
because it said I would be excluded from recieving updates. I think that's a
really stupid default setting.
It just happened again, and I noticed something else. The ld.so was not wedged,
but the autorun process was. It was stuck in a disk wait state, and the X server
was not able to be killed.
*** Bug 9616 has been marked as a duplicate of this bug. ***
Experienced this on yet another system with yet a different video card. Again,
happened while I was moving or resizing a Netscape window under KDE.
I was e-mailed directly by Dylan, so I'm adding his comments and my response to
the bugzilla ticket. I wonder if there's a way to do this directly by e-mail.
If not that would be a great feature to add to bugzilla.
Here's the e-mail:
> Has this been resolved?
> I'm trying to figure out if it's the same problem I'm having:
> when I try to drag a window, the whole machine locks up, can't
> switch virtual consoles, etc. Can't even c-alt-del to restart.
Yeah, that's the same bug. From talking to other people where I work
(Mission Critical Linux) I now think it's an X bug. If you catch it right
away, you can usually telnet into the box (if you have a network) and
reboot it, and I've heard that if you have certain console management
programs (can't recall which) you can actually kill X and reset the
console, then restart X. Haven't actually seen it work though, and I
don't remember what programs you need to do it.
If you don't have a network, you could also connect another computer
through your serial ports, and use seyon or minicom. This requires you to
run a getty on ttyS0 (or 1, depending on your system) so that you get a
login prompt on the serial port. Otherwise same principal applies.
If you don't catch it early (i.e. it locks up while you're away and you
return hours later) your machine will probably be hopelessly locked up.
We're having this happen hourly now on fresh-install, RH6.1 systems,
including after using update agent (this morning) to update everything
(except the kernel).
Our machines are Micron Millenia with Diamond viper 770 video cards.
I am having the same problem on three distinct machines, all three which are
Pentium MMX machines (200 Mhz and 233 Mhz desktops, one 233 Mhz both with fresh
installs, and also a Thinkpad 770 laptop with 2.2.14). I have not had any
problems as of yet on either Pentium II (2 machines, 450 Mhz each) or Pentium
III (600 MHz).
I have also noticed that the kernel continues to run (I can still listen to xmms
audio, and see ethernet card blinking as a I continue to download stuff).
However, X is completely locked. I use GNOME.
I also suspect glibc/gtk. Especially, I have noticed that the draw utilities in
glibc seem to not be mutex procected, since I have seen (for example) a plotting
program freeze during higher than norm screen refreshes while opening a menu in
or forcing an expose. The freeze always occurs on a glibc draw function.
This is an XFree86 problem, so I'm changing the component.
assigned to pbrown
does the problem persist if you uninstall autorun and/or magicdev?
closed due to lack of additional, necessary feedback.