Red Hat Bugzilla – Bug 174975
Obsolescent "DRM" version causes segfaults for "SuperSavage" chip
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.9.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 a segmentation fault. "OpenGL" screen
saver and similar applications make the "X" session crash
Expected Results: "DRI" should work beyond the first "X" session.
Upgrading to current "DRM" version 1.0.1 fixes the problem. No
segmentation faults anymore. The actual kernel module versions
reported by "dmesg" are:
[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.
I had posted this as bug 174906 previously for the "xorg-x11-server"
As reported in 174906 this is not just a Savage problem. All o radeon
cards are also freezing due to the same drm problem.
This statement is incorrect. Building current "DRM" for the "Radeon
7000" series, does not prevent the "X" server from freezing. This
is not the case for the "savage" module. Moreover, it only happens
when the "Mesa" libaries are actually used, e.g. by executing "glxinfo".
Finally, the "savage" bug does not lead to a freeze of the "X" server,
but merely makes it abort. One is thus simply ejected from the current
"X" session and can/has to log in again.
The bug reported here is thus very different from the lock-ups on
Radeon chips that you report in a comment to bug 174906.
Yes, you are right. I did compile to new drm into the latest kernel and
radeon is still freezing.
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.
I pointed the upstream drm maintainer at this bug. His reponse..
"No idea what is causing the problem there...
If you can get a dmesg with debug on for the DRM with the savage failing..
I might be able to figure it out."
It may speed things up if you work directly with him (email@example.com)
Feel free to cc: me on any mail.
Thanks, I am going to investigate this in detail. For the time being,
I want to point out that there is an independent bug report on the
same issue for the Linux kernel:
In the meantime, I have updated my Xorg RPMS to version 6.9. The problem
seems to persist though.
I have found out that not the very update to "DRM" version 1.0.1 keeps
"Mesa" from segfaulting. As a matter of fact, what made the difference
was loading the "savage.ko" module explicitly. Appending "modprobe
savage" to "rc.sysinit" makes it impossible for me to reproduce the
segmentation faults reported earlier. Before, I loaded the compiled
"savage.ko" built from current "DRI" snapshots and corresponding to
"DRM" version 1.0.1 via "insmod".
However, even loading the original kernel module delivered as part of
kernel 2.6.14-1.1653_FC4 corresponding to "DRM" version 1.0.0 makes
the reported behaviour disappear.
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.
You should really take this to the dri developers at their bugzilla at
Those guys are in a much better position to debug problems with snapshots.
This has already been done, see:
However, as I pointed out it's just not a "DRI" snapshot matter. It's
a matter of the regular "drm.ko" and "savage.ko" modules delivered
with the Fedora kernels, in particular 2.6.14-1.1653_FC4 and the
rawhide/pre-FC5 kernels. David Airlie is also actively involved in
investigating this problem, see:
He already announced to commit updated "DRM" code to the Linux kernel
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.
I've temporarily had to revert the DRI changes whilst some bugs that prevent X
startup on some systems are worked out.
should be fixed in current builds.