Red Hat Bugzilla – Bug 174906
"Mesa" segfaults on "SuperSavage" at 2nd consecutive "X" session
Last modified: 2015-01-04 17:23:31 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051018 Epiphany/1.8.2
Description of problem:
Direct rendering on my "IBM ThinkPad T23" is up and running
after booting the machine. The video chip is an "S3 Inc.
SuperSavage IX/C SDR rev 5". "glxinfo" reports that direct
rendering is enabled and 3D hardware acceleration is ok.
However, after logging out and in again, execution of
"glxinfo" triggers a segmentation fault. "DRI" enabled
applications make the "X" session abort instantaneously.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Log in to "X" session.
2. Check proper working of "DRI". Ok, it works.
3. Log out and log in again.
4. Check proper working of "DRI" again.
Actual Results: "glxinfo" reports "Segmentation fault". "OpenGL" screen
saver and similar applications make the "X" session crash
Expected Results: "DRI" should work beyond the first "X" session.
This bug already affected my own experimental monolithic
"Xorg" builds since August 2005 based on Mike Harris'
initial RPM packages including "Xorg 6.9 RC2".
You are better off than I am on ThinkPad T42 with Radeon 9600 M10 and Dell Precision
with Radeon 7000 VE. They both freeze the computer if "Load dri" is included.
I have the same problem with my desktop PC which is equipped with a
Radeon 7200 (R100 QD) graphics card. It also freezes. However,
your comment is off-topic. This bug report exclusively deals with
the "savage" driver.
Post to the corresponding bug report please or open a new bug report
Upgrading to the current DRM version fixes the problem. No segmentation
faults anymore. The actual kernel module versions according to "dmesg"
[drm] Initialized drm 1.0.1 20051102
[drm] Initialized savage 2.4.1 20050313 on minor 0:
Please consider updating kernel DRM to the current version.
Please report this problem to X.org bugzilla located at
http://bugs.freedesktop.org in the "xorg" component, so that any problems
with the "savage" 2D and/or 3D driver can be addressed prior to the official
Once you've filed the bug in X.Org bugzilla, please paste the URL here and
Red Hat will track the problem in X.Org bugzilla and consider applying
any patches that become available in a future development build.
Additionally, if our kernel DRM is too old, please file a bug against the
"kernel" component in Red Hat bugzilla, as that is where the DRM source
code is built which ships in our kernel. The DRM source in the X source
code is not used by our kernel, so all DRM related bug reports should always
be filed against the kernel component.
Thanks in advance.
Setting status to "NEEDINFO_REPORTER", and awaiting upstream bug URL for
Bug 174975 filed against the kernel component for using obsolescent
"DRM" version. Current version is 1.0.0, upstream version is 1.0.1.
Looks pretty much like:
I have asked to check against current "DRM". Unless I receive feedback
from other concerned users within a reasonable amount of time, I will
open a separate bug report and report it here.
After reverting my system to FC4, I have built monolithic RPMs of
Xorg 6.9-RC3. They exhibit the same bug. The 2nd login makes
Mesa segfault. Building kernel modules of the current DRM version
1.0.1 again settles the problem.
Even the current DRM version 1.0.0 works, if it is loaded "by hand"
some time during the boot procedure. Because I "insmodded" the
self-built module anyway via "rc.sysinit", I got misled.
Appending "/sbin/modprobe savage" does the job, too. No "DRM" update
is thus required. Consequently, it might be a problem with "initscripts"
or "udev". I have to check next, if the bug is Red Hat specific or not.
Essentially the same problem occurs after bootig from a Ubuntu 6.04
alpha Live CD. The (modular) X server release is 7.0.0 RC4. It is
thus not Red Hat specific.
Fixed in "kernel-2.6.15-1.1853_FC5" (2.6.15-git9) by "DRM" upstream
update to version 1.0.1 committed by D. Airlie.
While X does contain DRM source code, we do not use that DRM source. The
DRM source used in the OS, is part of the kernel.
Reassigning to kernel component...
DRM changes temporarily reverted due to other problems needing to be worked out
should be fixed in current builds