Red Hat Bugzilla – Bug 52325
Xscreensaver module 'Lament' crashes X server
Last modified: 2008-05-01 11:38:00 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Description of problem:
The xscreensaver module 'Lament' crashes the running X server after a
couple of minutes, thus exiting the current X session abruptly.
Version-Release number of selected component (if applicable):
3.33-3 (and previous)
Steps to Reproduce:
1. Choose 'Lament' module of xscreensaver via control-center
2. Wait a couple of minutes ... .
Actual Results: X session is abruptly terminated after several minutes.
Expected Results: Screen saver should have remained active until DPMS
Actual X server is XFree86* with mga module (MGA Millennium II PCI 8MB)
Do the other 3D screensavers do that? It would be interesting to see your
/etc/X11/XF86Config-4 and /var/log/XFree86.*.log with the crash info. Attach
those individually using the link bellow.
Changing component to XFree86
This 'lament' xscreensaver module is the only one (of those tested) that leads
to this abnormal behaviour. I tried out many other GL based modules - they all
worked well. XF86Config-4 and log files show no particular anomalies. The former
was created with Xconfigurator without any modification (except for an
additional font path entry).
I've tried it on a millenium 1 here; it's been running fine for about 15 minutes
It has turned out that the abovementioned problem only occurs in SMP mode
(platform is a dual Pentium Pro INTEL PR440FX). After booting into single
processor mode, 'lament' works as expected (neither crash nor anything else).
Odd. Please attach the previously requested files (config and log)
so I can reproduce your setup. Also, attach any relevant errors
from your kernel messages log.
Just an extra datapoint, I have been running Lament on a Voodoo III
with DRI for 24 hours on a dual 1Ghz box with SMP kernel 2.4.7-2 with
no problems.. if it is a problem, it could be mga driver specific,
or it could be you're not using the latest rawhide packages of everything.
Ok, I have added some attachments which show that this seems to be a GNOME
problem. Login as 'install' at 11:47:44, X session is aborted at 11:56:28 while
the screen saver is active. No further action after logging in.
Created attachment 29635 [details]
XFree86 version 4 configuration file
Created attachment 29636 [details]
XFree86 version 4 log file
Created attachment 29637 [details]
extract of kernel message log file
Created attachment 29638 [details]
This may be irrelevant, but anyway, Did you notice that your 8 Mb card uses
only 4 Mb by default? I think you should specify the memory in the config file:
VideoRam 8192 <--- add this line
Also, you are pretty demanding of your hardware. 1400x1050x24bpp will take all
your almost all your videoram. Lament, this is just my guess, needs some extra
for textures. Can you reproduce the problem at lower resolutions, say 800x600?
I have tried out various resolutions down to 800x600 as well as different color
depths. Unfortunately, this has had no positive effect (though VideoRam set to
8192 now). System is a clean installation of Red Had Linux 7.1.94 (Roswell 2).
You're using an 8Mb card... with an extremely high res... with DRI enabled?
That is not going to work. Even on a 16Mb card, I would expect it to fail
miserably at that resolution. DRI is memory needy. Disable DRI.
According to th previously attached X server log file, "DRI" was not initialized
anyway: "(EE) MGA(0): Static buffer allocation failed, not initializing the DRI
(EE) MGA(0): Need at least 9843 kB video memory at this resolution, bit depth".
As a consequence, commenting the "DRI" related entries in the "XF86Config-4"
file out does not change anything at all. This appears logical from the users's
point of view, as I have never requested "DRI" support explicitly, and I
should't be bothered with optional configuration options that are not required
for normal operation.
Furthermore, I had reported that this problem only occurs as long as the SMP
kernel is used. It is thus likely to be a video driver problem at the kernel
level. Unfortunately, SMP kernels are much less stress tested that uni-processor
kernels, resulting in further anomalies that I have observed like speeding up
the system clock under network load (bug #53914)! However, XFree86-SVGA-3.3.6-42
turned out to work properly.
After upgrading to "kernel-2.4.9-7" of Red Hat Linux 7.2 (ENIGMA) updates, the
reported behaviour has (fortunately) disappeared. "Lament" is working properly
now, even in SMP-mode (Sorry, I haven't tried the stock "2.4.7-10" kernel). By
the way, XFree86 has not been upgraded and is still version "4.1.0-0.9.13" of
Closing bug as fixed in Enigma (Red Hat Linux 7.2)