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): kernel-2.6.14-1.1739_FC5 How reproducible: Always 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 immediately. Expected Results: "DRI" should work beyond the first "X" session. Additional info: 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" component.
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. Thanks
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 (airlied) 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: http://bugzilla.kernel.org/show_bug.cgi?id=5784 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 http://bugs.freedesktop.org Those guys are in a much better position to debug problems with snapshots.
This has already been done, see: https://bugs.freedesktop.org/show_bug.cgi?id=3835 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: http://bugzilla.kernel.org/show_bug.cgi?id=5784 He already announced to commit updated "DRM" code to the Linux kernel tree.
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.