Bug 52325 - Xscreensaver module 'Lament' crashes X server
Xscreensaver module 'Lament' crashes X server
Status: CLOSED CURRENTRELEASE
Product: Red Hat Public Beta
Classification: Retired
Component: XFree86 (Show other bugs)
roswell
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-22 16:08 EDT by Joachim Frieben
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-26 11:42:52 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)
XFree86 version 4 configuration file (1.99 KB, text/plain)
2001-08-26 06:18 EDT, Joachim Frieben
no flags Details
XFree86 version 4 log file (20.52 KB, text/plain)
2001-08-26 06:19 EDT, Joachim Frieben
no flags Details
extract of kernel message log file (2.12 KB, text/plain)
2001-08-26 06:19 EDT, Joachim Frieben
no flags Details
xsession-errors file (896 bytes, text/plain)
2001-08-26 06:21 EDT, Joachim Frieben
no flags Details

  None (edit)
Description Joachim Frieben 2001-08-22 16:08: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)

How reproducible:
Always

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 
sets in.

Additional info:

Actual X server is XFree86* with mga module (MGA Millennium II PCI 8MB)
Comment 1 Alexei Podtelezhnikov 2001-08-22 17:57:19 EDT
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.
Comment 2 Glen Foster 2001-08-22 17:58:06 EDT
Changing component to XFree86
Comment 3 Joachim Frieben 2001-08-22 19:11:54 EDT
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).
Comment 4 Bill Nottingham 2001-08-22 22:44:10 EDT
I've tried it on a millenium 1 here; it's been running fine for about 15 minutes
so far...
Comment 5 Joachim Frieben 2001-08-23 07:15:54 EDT
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).
Comment 6 Mike A. Harris 2001-08-24 05:57:02 EDT
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.
Comment 7 Mike A. Harris 2001-08-24 05:58:32 EDT
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.
Comment 8 Joachim Frieben 2001-08-26 06:16:47 EDT
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.
Comment 9 Joachim Frieben 2001-08-26 06:18:05 EDT
Created attachment 29635 [details]
XFree86 version 4 configuration file
Comment 10 Joachim Frieben 2001-08-26 06:19:16 EDT
Created attachment 29636 [details]
XFree86 version 4 log file
Comment 11 Joachim Frieben 2001-08-26 06:19:59 EDT
Created attachment 29637 [details]
extract of kernel message log file
Comment 12 Joachim Frieben 2001-08-26 06:21:24 EDT
Created attachment 29638 [details]
xsession-errors file
Comment 13 Alexei Podtelezhnikov 2001-08-26 14:55:16 EDT
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:
Section "Device"
          VideoRam    8192    <--- add this line
EndSection

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? 
Comment 14 Joachim Frieben 2001-08-27 17:43:36 EDT
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).
Comment 15 Mike A. Harris 2001-10-16 13:16:38 EDT
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.
Comment 16 Joachim Frieben 2001-10-17 08:28:24 EDT
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.
Comment 17 Joachim Frieben 2001-10-26 11:42:48 EDT
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
Roswell 2!
Comment 18 Mike A. Harris 2001-10-27 18:54:00 EDT
Closing bug as fixed in Enigma (Red Hat Linux 7.2)

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