Bug 188228

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 ***