Created attachment 127446 [details] Xorg.0.log
Description of problem: My system is running FC5 with selective updates from rawhide, as noted below. When I start X without load dri/drm directives in xorg.conf glxinfo reports the mesa s/w GL renderer, which works with glxgears/xscreensaver but obviously eats CPU, this in itself is an improvement over what I had in the rawhide period before FC5. When I start X with load dri/drm directives in xorg.conf I r300_dri.so loads succesfully, glxinfo reports the Tungsten/DRI GL renderer, this is vast progress over what I had from rawhide (before FC5 withdrew the r300 stuff for stability reasons) attached is my Xorg.0.log However when running any GL program e.g. glxgears it exits with drmRadeonCmdBuffer: -22 (exiting) and dmesg gives [drm:r300_emit_3d_load_vbpntr] *ERROR* Offset failed range check (k=0 i=2) while processing 3D_LOAD_VBPNTR packet. [drm:r300_emit_packet3] *ERROR* r300_emit_raw_packet3 failed [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet3 failed Version-Release number of selected component (if applicable): mesa-libGL.i386 6.5-1 mesa-libGL.x86_64 6.5-1 mesa-libGLU.i386 6.5-1 mesa-libGLU.x86_64 6.5-1 mesa-libGL-devel.x86_64 6.5-1 xorg-x11-server-Xorg.x86_64 1.0.99.2-1 xorg-x11-drv-ati.x86_64 6.5.7.3-4.cvs20060404 xorg-x11-apps.x86_64 1.0.2-1 kernel.x86_64 2.6.16-1.2121_FC6 How reproducible: 100% Steps to Reproduce: 1. start x with dri/drm 2. glxgears Additional info: My card is a PCIe X550
Added reference to fd.o bugzilla
PCIE r300s are known to be broken in Mesa 6.5. There's a fix upstream, just need to pull it back in...
Ok, please put this fix in the mesa rpm, so that DRI/DRM and 3d acceleration with MESA works with Xorg 7.x and kernel 2.6.16 and ATI Radeon X600 (>=R300). It's not the best that Xorg needs new kernel to run with DRM/DRI. In the old days, the X11 server works independently of changes in the kernel. Now we need to update Xorg and the kernel. Maybe someday X600 (R300) with Mesa and DRI/DRM works with FC5.. (Remember: The Icons (left-upper-corner) from the BIOS are still broken with FC5 and Xorg 7.x - in FC4 it was ok.) Thanks.
(In reply to comment #4) > Ok, please put this fix in the mesa rpm, so that DRI/DRM and 3d acceleration > with MESA works with Xorg 7.x and kernel 2.6.16 and ATI Radeon X600 (>=R300). I'll try to hit this soon, I've been clearing out some of the stability issues with R300 first. It's not a big win to go from totally broken to works for three seconds... > Maybe someday X600 (R300) with Mesa and DRI/DRM works with FC5.. > (Remember: The Icons (left-upper-corner) from the BIOS are still broken with FC5 > and Xorg 7.x - in FC4 it was ok.) One report per bug, please.
(In reply to comment #5) > One report per bug, please. Ok, one bug per one new FC release please ;-) Well, for the X600 (R300) graphic hw FC5 with Xorg 7.x is really buggy - FC4 was much better in this case. BTW: There's one bug open with the icon problem.. I just wondering, that nobody at redhat has a PC/ laptop with a R300 graphic hw and can test this before release the packages. But I know, you do what you can to fix this issue. Thanks.
See Bug # 189471
(In reply to comment #4) > Ok, please put this fix in the mesa rpm, so that DRI/DRM and 3d acceleration > with MESA works with Xorg 7.x and kernel 2.6.16 and ATI Radeon X600 (>=R300). That will eventually happen, if it hasn't already. > It's not the best that Xorg needs new kernel to run with DRM/DRI. Definitely agree. Unfortunately, the reality of things is that it sometimes does happen upstream, and we have to live with it, as do all users, as we do not control what upstream decides to do. Knowing upstream however, they do not ever make gratuitous changes to things that break compatibility unless it is something that *has* to be done to fix something, and there is no easy way to provide backward compatibility. So while this is definitely avoided like the plague, it is in fact sometimes necessary, because developers do not write perfect code, nor have a crystal ball that can detect the future. ;o) > In the old days, the X11 server works independently of changes in > the kernel. I'm not really sure what your definition of "old days" might be, but we have had issues like this for at least 4-5 years. The kernel rpm contains "Provides: kernel-drm = 4.3.0" (or other values depending on the OS release and kernel rpm in question) for literally years. Prior to that we had kernel-drm = 4.1.0 listed, as well as other values. That was done explicitly so that our X rpms could enforce that a particular minimum version of the DRM was present. Of course, it only works for people who use Red Hat binary kernels as far as enforcement goes, but it did cut down on unnecessary bug reports, even though one would seriously hope that such a Provide/Require would never be necessary. > Now we need to update Xorg and the kernel. Yes, that's unfortunate. I definitely hate it when this happens, and even more so than any one user does, because I happen to be on the receiving end of all the bug reports, complaints, whines, and I myself join such users in choir, as I hate it too. We all have to live with it though in the name of upstream progress. If this did not happen, then the X server and drivers would have permanent and unfixable bugs in them that people would just have to live with, in the name of compatibility. ;o) > Maybe someday X600 (R300) with Mesa and DRI/DRM works with FC5.. That's entirely likely. We plan on releasing X11R7.1 for FC5 some time in the future "when it feels right" to us. Assuming the r300 DRI support is stable and useable at that time, we'll consider including it in FC5 also. I'm really hoping that is doable. We'll see... > (Remember: The Icons (left-upper-corner) from the BIOS are still broken with FC5 > and Xorg 7.x - in FC4 it was ok.) I vaguely remember reading a bug report of that nature, but IIRC it was an obscurish bug report, which would require having the exact physical hardware the problem occured on, in order to reproduce and diagnose. While that's unlikely to happen, what's more likely is that a future random update of something will magically fix it some time. ;) Anyhow, I'm talking with davej and others to figure out how we can handle the DRM update issue in rpm packaging context. I'll try to remember to post an update here if we figure something out. In the mean time, please provide updates if you notice anything changes for the better or worse in rawhide, or in FC5, as that would be useful feedback. Thanks for your comments! Take care, TTYL
*** This bug has been marked as a duplicate of 195782 ***