Red Hat Bugzilla – Bug 91087
screensaver (GL) would hang the system
Last modified: 2005-10-31 17:00:50 EST
Description of problem:
I am using RH 8.0 and I have up2date-d to your latest Kernel 2.4.20-13.8
and all the other newest patches (including KDE).
After that, whenever the KDE screensaver wants to any screensavers which
has "(GL)" in its names such as PIPES, SPACES etc., the system
would just hang. I found out by going to the "Control Panel" -> click
screensaver -> click PIPES (GL) and then it'd hang !!!
When it hung, I could login from another machine by ssh and when I execute
the "top" command, I see :
1376 kinyip 15 0 50688 10M 7304 R 98.4 1.0 2:37 kpipes.kss
1669 kinyip 20 0 50556 9M 7320 R 99.2 0.9 0:16 kspace.kss
Version-Release number of selected problem.component (if applicable):
Every time !
Steps to Reproduce:
I found out by going to the "" -> -> !!!
1. In KDE, Start "Control Center" (from the "Start Application" redhat button)
2. click screensaver under "Look and Feel"
3. click PIPES (GL)
4. then it'd hang
It hangs every time I choose GL screensavers.
It should not hang and let me test/setup the screensaver.
it looks like a config problem in XFree86. I assigned it to correct component
Attach your /var/log/messages , X server config file, X server log file
to the report from just after experiencing one of these hangs. Be sure that
the "messages" file contains info right from boot time onward if possible
Created attachment 91871 [details]
/var/log/messages from boot to crash
This is the file /var/log/messages. I include from the beginning of a boot to
when the problem
occured (screen hung).
Those "session opened ..." were when I logged in from another host by ssh.
Created attachment 91872 [details]
XF86Config from /etc/X11
This XF86Config file is from /etc/X11 .
Created attachment 91873 [details]
This is XFree86.0.log is from /var/log .
This is XFree86.0.log is from /var/log .
What kernel modules are you using on your system which do not come as a part
of Red Hat Linux? Your kernel is tainted.
Please disable all 3rd party kernel modules, wether they are of proprietary
origin or open source, and then reboot without loading any external modules.
After you have reproduced the problem without tainted modules, please attach
a new X server log and kernel log from after a crash. Please be sure
to include the exact logs from the crash, and not a new log generated from
after you rebooted.
Thanks in advance.
Why do you say that the kernel module is tainted ?
I am using the kenerl 2.4.20-13.8 that is in your newest patch.
The only module that I think I've added in addition to your RH stuff
is the (open)AFS module. I don't have any other non-RH module.
I can do something to take it out. But I want to make sure that this
is what you're talking about ?
Could you please confirm ?
And of course, I gave you the part of /var/log/messages before the
system was rebooted.
Is /var/log/XFree86.0.log the right log file for X server ?
>Why do you say that the kernel module is tainted ?
Your kernel has had a kernel module that does not ship with Red Hat Linux,
which has been force loaded into the kernel with "modprobe -f".
Either of those scenarios will taint the kernel. We do not support systems
which have had kernel modules loaded which we did not ship. Users who have
problems while running a tainted kernel in which the system locks up, we
require to reproduce the problem with a stock supported Red Hat Linux kernel
with no 3rd party kernel modules.
>The only module that I think I've added in addition to your RH stuff
>is the (open)AFS module. I don't have any other non-RH module.
That is likely what is tainting the kernel.
>I can do something to take it out. But I want to make sure that this
>is what you're talking about ?
Yes, disable any non Red Hat kernel modules from being used, then reboot.
Make sure that your initscripts and boot process do not load any non
Red Hat kernel modules.
>Is /var/log/XFree86.0.log the right log file for X server?
That is correct. If there is an /var/log/XFree86.0.log.old, you might
want to attach it also.
This is probably a DRM related problem, however I have to make sure that
it happens without external kernel modules first.
Created attachment 91905 [details]
from booting to crash ...
This is hopefully the good part of /var/log/messages that you want.
I have included the part of "messages" from the booting stage to the end after
it hung and I needed to reboot.
Created attachment 91907 [details]
/var/log/XFree86.0.log is attached. But it doesn't really show anything.
I indeed provide here the XFree86.0.log for the section when it crashed/hung.
But there seemed to have no error messages logged in this file.
There is nothing like XFree86.0.log.old
I forgot to say that the last two log files that I submitted were
the log files when I removed the AFS module.
So, when I do "lsmod", indeed, AFS module was indeed not there.
Adding to this, I've experienced the same behaviour with GL screensavers hanging
my machine when running the 2.4.20-13.7 and 2.4.20-18.7 kernels, though this
problem does not occur when running the 2.4.18-27.7 or prior kernels. I am
running RedHat 7.1 on a P4 1.6GHz machine with an ATI Radeon VE video card and
don't have any non-RedHat kernel modules loaded. After the hang, I get a black
screen (though the monitor is not in power-saving mode) and while the keyboard
and mouse are not responsive, I can usually log in to the machine remotely (I
needed a hard reboot twice while trying to track down the problem when the
machine was dead to the world). Killing X remotely does not solve the problem -
I need to reboot and only get my screen back once I reach the BIOS memory check
at start (i.e. I don't even see the shutdown procedure text messages scroll by).
Let me know if you want copies of anything.
Is there any progress on this ? Any solution ? Would RedHat 9.0
solve this problem ?
I am getting more and more anxious to use the OpenGL. It seems to have
Also, throughout the bug report your supplied data has shown that you
are using kernels with 3rd party kernel modules loaded, or are unloading
them once they're loaded. You must not ever load any 3rd party modules,
because once the module is loaded, your kernel is unsupported - even if
you subsequently rmmod the module - it HAS been in the kernel and MAY have
created the problems you are experiencing. Wether or not it "has" done so
doesn't matter, since your system is unsupported once it has loaded an
unsupported kernel module.
In order to allocate resources to investigate this issue, first requires
that I see very strong evidence in the bug report that the problem occurs
by a stock Red Hat Linux system with all official Red Hat Linux updates
applied, including the kernel. While that is potentially the case, I
do not see compelling evidence yet to support that.
Red Hat Linux 8.0 is in security fixes only mode right now as well, so any
non-security related reports will be of very low priority aside from all
Your best bet, is to upgrade to Red Hat Linux 9, and then apply all officially
released Red Hat updates. If the problem recurs on that OS release, using only
the Red Hat Linux 9 kernel with absolutely no 3rd party (proprietary, GPL or
otherwise) kernel modules ever loaded since boot time, if you can provide
detailed troubleshooting information, and reproduceability information, then
when I have time to investigate this type of bug report (which wont be for
a minimum of 2 months at least), I can attempt to reproduce the problem.
Apparently, after I upgraded to RedHat 9.0, this problem disappears.
It doesn't matter whether I have only RedHat or install additional
non-RedHat stuff or used non-RedHat configuration. It always works
in RedHat for those GL graphics/images.
Closing bug as "CURRENTRELEASE" of Fedora Core 2, as per comment