ATI Radeon R100 QD (7200) refuses to work with Compiz (Kernel 2.6.34-rc4)

[Michel Dänzer]

On Son, 2010-04-25 at 11:35 +0200, Uwe Bugla wrote: 
> Am Samstag, den 24.04.2010, 12:31 -0400 schrieb Alex Deucher:
> > On Sat, Apr 24, 2010 at 11:48 AM, Chicken Shack <chicken.shack at gmx.de> wrote:
> > > Am Donnerstag, den 22.04.2010, 01:36 -0400 schrieb Alex Deucher:
> > >> On Mon, Apr 19, 2010 at 4:25 AM, Uwe Bugla <uwe.bugla at gmx.de> wrote:
> > >> > Hi,
> > >> > I am running kernel 2.6.33-rc4 on a Debian Testing Squeeze release.
> > >> > I have debianized the latest driver snapshot from
> > >> > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati.
> > >> >
> > >> > So I am using the ATI driver version 6.13 in connection with the latest
> > >> > Radeon driver in kernel with KMS enabled.
> > >> > Everything is fine so far, until I try to start Compiz:
> > >> >
> > >> > "drmRadeonCmdBuffer: -12. Kernel failed to parse or rejected command
> > >> > stream. See dmesg for more info."
> > >>
> > >> What does dmesg say?  This looks like a dupe of bug 26302:
> > >> https://bugs.freedesktop.org/show_bug.cgi?id=26302
> > >>
> > >> Alex
> > >>
> > >> >
> > >> > This is the message when Compiz is started via "compiz --replace &"
> > >> >
> > >> > The card's memory is 32 MB Video RAM - it's a quite old one :))
> > >> >
> > >> > I do NOT use a specified xorg.conf in connection with
> > >> > xserver-xorg-1.7.6, as it is a new driver where everything is being
> > >> > managed via KMS.
> > >> >
> > >> > And that's it what Gnome's System Information spurks out under Computer
> > >> > -> Display:
> > >> >
> > >> > Vendor          Tungsten Graphics, Inc.
> > >> > Renderer        Mesa DRI R100 (R100 5144) 20090101 x86/MMX/SSE2 TCL DRI2
> > >> > Version         1.3 Mesa 7.9-devel
> > >> > Direct Rendering Yes
> > >> >
> > >> > So everything is OK except the "-12" kernel crash above, performed every
> > >> > time when I try to start Compiz Fusion.
> > >> >
> > >> > Any idea or patches available?
> > >> >
> > >> > Thanks!
> > >> >
> > >> > If you need further information please ask me for it.
> > >> >
> > >> > Uwe
> > >> >
> > >> > P. S.: I compile the Mesa Library as described in the Internet, but with
> > >> > two exceptions:
> > >> >
> > >> > a. I do not take the master branch, I prefer Luca Barbieri's
> > >> > nvfx-next-branch instead because I need
> > >> > a working solution for my two Nvidia NV34 cards, and Compiz works if I
> > >> > use that branch while the master
> > >> > repo is not yet compatible with Compiz.
> > >> >
> > >> > b. I do not take "disable-gallium" as a configure switch, I prefer
> > >> > "-enable gallium-nouveau" instead because
> > >> > I do need a functionable Gallium nouveau driver too when compiling the
> > >> > mesa library.
> > >> >
> > >> > c. When will Luca Barbieri's nvfs-next-tree be synchronized with the
> > >> > master tree?
> > >> >
> > >> > d. Is it possible that the current ATI driver's texture size is erratic
> > >> > (i. e. too big)? I have no idea where the error could result from!
> > >> >
> > >> > e. Although stated differently in the error message above neither the
> > >> > dmesg nor the xorg.0.log file reveal any information that could be
> > >> > really helpful.
> > >> >
> > >> >
> > >> >
> > >
> > > Hi Alex,
> > >
> > > 1. The real issue of that Compiz problem IS NOT what dmesg says.
> > >
> > > The real issue of my problem is that the FIRST patch Dave Airlie
> > > attached for resolving this Compiz issue NEVER reached kernel mainline
> > > while the second one did obviously.
> > >
> > > So PLEASE do push up Dave's FIRST patch titled "fallback on VRAM memory
> > > placement" as fast as possible so that it becomes part of the kernel
> > > mainline!
> > 
> > The first patch caused problems on some AGP systems due to the
> > unreliability of AGP so it wasn't pushed to mainline.  It should be
> > safe to push once this patch hits mainline:
> > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=61cf059325a30995a78c5001db2ed2a8ab1d4c36

No, there were more issues with the patch[0] and it can't be pushed
again as is. A different approach will be needed to make things work
better on VRAM-limited systems.


[0] At least making pinning of BOs to VRAM unreliable, potentially
causing problems with BOs used by the display hardware (e.g. trying to
start a second X server when VRAM is full of BOs), and degrading
performance on systems where things work without the patch.

-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer