Bug 118714 - reproducible X crash with radeon 7000 and antspotlight screensaver
reproducible X crash with radeon 7000 and antspotlight screensaver
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-19 08:24 EST by Noa Resare
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-09 17:37:30 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)
the XFree86.0.log really should get a better name (42.29 KB, text/plain)
2004-03-19 08:25 EST, Noa Resare
no flags Details
XFree86.0.log.old (40.90 KB, text/plain)
2004-03-19 13:54 EST, Noa Resare
no flags Details
XF86Config (3.11 KB, text/plain)
2004-03-19 13:55 EST, Noa Resare
no flags Details

  None (edit)
Description Noa Resare 2004-03-19 08:24:10 EST
Description of problem:

When I try to enable the antspotlight screensaver X reliably dies with
my newly recompiled xorg-x11 x server.

The screen turns almost black with some blocky gray patterns that
resembles graphics bugs on my friends' C64's that I saw when I was a
kid. The keyboard is unresponsive and I can't use ctrl-alt-f1 to
switch to console.

Logging into the box remotely and running 'killall -9 X' creates a
colorful ansi character screen for about a second before X dies and
gdm restarts it.


Version-Release number of selected component (if applicable):
xorg-x11-0.0.6.6-0.0.2004_03_11.5

How reproducible:
always

Steps to Reproduce:
1. go to screensaver control panel.
2. select antspotlight screensaver
3. 
  
Actual results:
X death, as explained above

Expected results:
no X death

Additional info:
I use a locally recompiled xorg-x11-0.0.6.6-0.0.2004_03_11.5.src.rpm
(the one from the devel tree depended on a new glibc) that I installed
with --nodeps work around packages that required XFree86.

The system is a fedora core 1 + released updates system.

For some reason /usr/X11R6/lib disappeared from /etc/ld.so.conf when
doing the update, so the %postinstall script for xorg-x11-100dpi-fonts
failed (mkfontdir misssed it's shared libraries). After manaully
adding /usr/X11R6/lib and running ldconfig i redid the installation
with --force to make sure all the %post scripts was really run.

I guess this problem is due to some bad interation with rawhide
XFree86 that I had installed before (4.3.0-63 it seems) and it
shouldn't affect the above filed bug report but I thought I should
mention it anyway.
Comment 1 Noa Resare 2004-03-19 08:25:03 EST
Created attachment 98681 [details]
the XFree86.0.log really should get a better name
Comment 2 Noa Resare 2004-03-19 08:26:46 EST
While I'm at it: Please use .bz2 for the xorg-x11 source and save me
~12 MiB of download from download.fedora.redhat.com (development
packages propagate rather slowly to my local mirror)
Comment 3 Mike A. Harris 2004-03-19 12:56:55 EST
>I use a locally recompiled xorg-x11-0.0.6.6-0.0.2004_03_11.5.src.rpm

We do not support customer/user recompiled packages.  However, having
said that, the ld.so.conf problem is already known since Wednesday,
and a fix was attempted in the 0.0.6.6-0.0.2004_03_11.6 package.

The actual bug is not a bug in xorg-x11, but in the XFree86-libs
package that gets uninstalled.  It's %postun removes the X lib
dir from ld.so.conf.  All the new packages can do, is try to put
it back, which they do.  RPM itself decides what order the various
package's pre/post/postun/preun/etc. scripts run in however, and
so there may not be any way for me to force xorg-x11 packages
to ensure ld.so.conf is correct.

> the XFree86.0.log really should get a better name

The log name is $PROGRAMNAME.$DISPLAY_NUMBER.log

It is possible to have multiple X server's running on a machine
all at the same time, each on it's own display, so the log files
must contain the $DISPLAY number or else there is contention
with multiple servers writing to the same log or overwriting the
same log.  Since it is possible to run multiple different X
servers at the same time, the name of the program needs to be
in the log filename.  The extension ".log" is just common for
Linux/UNIX style log files.

The log files will get renamed to Xorg.$DISPLAY.log in the near
future once we update to the latest upstream changes that
incorporate the name change, however Red Hat does not determine
what the name used is, rather the X.org people will decide.  Whatever
is decided, Red Hat will use, in order to be consistent with the
upstream naming.

>While I'm at it: Please use .bz2 for the xorg-x11 source and save me
>~12 MiB of download from download.fedora.redhat.com (development
>packages propagate rather slowly to my local mirror)

bz2 compressed main tarball takes double the time to decompress it
every time I rebuild the rpm package, or approximately an extra
minute to a minute and a half over gzip -9.  As such, I changed
from using bzip2 to tar.gz a long time back in order to help speed
up my local test builds, as build speed performance is important
to me.  While I plan on continuing to use tar.gz for the forseeable
future, I will switch to bzip2 compressed sources once the X.org
source tree gets split up into much smaller pieces which can be
put into individual src.rpms, as the time it takes to decompress
the main tarball will then be significantly smaller, and much
less of an inconvenience to me in my daily work.

In the mean time, if download time is a hindrance for you, you can
instead try exploding the src.rpm on a fast remote machine, and then
using rsync to download the patches/spec locally.  I use this
technique to transfer the src.rpm contents to/from Red Hat and it
is very effective in minimizing network transfer overhead.  It
takes me about 45 seconds to upload a new src.rpm to Red Hat in this
way.

Hope this helps.

Comment 4 Mike A. Harris 2004-03-19 12:59:48 EST
For your Radeon problem, please reinstall the officially provided
Red Hat binary rpm packages.

While it likely the problem exists in the Red Hat packages as well,
it is also possible that your recompilation may have introduced a
problem that is not present in our binaries, and we need to rule
that possibility out.

Please attach the log file and config file from using the Red Hat
built rpms.

Thanks in advance.
Comment 5 Noa Resare 2004-03-19 13:53:30 EST
Thanks for taking the time to explain why .tar.gz. Supporting only
rh-built pacakges seem perfectly reasonable also.

Regarding download times, I have access to several boxen with 10mbit/s
connections up here in northen europe (sweden) but no one have faster
downloads from download.fedora.us than 10kb/s. It doesn't matter today
because it seems ftp.funet.fi has picked up the latest development tree.

Someday I'll write a rpmdiff utility that creates nice small diffs for
binary rpm packages :)

I have now reproduced the X death with Build Host:
tweety.devel.redhat.com. Attaching log and config file below.
Comment 6 Noa Resare 2004-03-19 13:54:27 EST
Created attachment 98689 [details]
XFree86.0.log.old
Comment 7 Noa Resare 2004-03-19 13:55:48 EST
Created attachment 98690 [details]
XF86Config
Comment 8 Noa Resare 2004-04-09 17:37:30 EDT
I can no longer reproduce the problem with
xorg-x11-0.6.6-0.2004_03_30.5 from the development tree

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