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

[Dave Airlie]

2010/4/25 Michel Dänzer <michel at daenzer.net>:
> 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.

Yeah I'm going to try and fix that up this week now we fixed the AGP.

I'm just going to separate the pinning code from the validate code wrt
domain->placement translation.

Dave.

>
> --
> Earthling Michel Dänzer           |                http://www.vmware.com
> Libre software enthusiast         |          Debian, X and DRI developer
> _______________________________________________
> xorg at lists.freedesktop.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.freedesktop.org/mailman/listinfo/xorg