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 <[email protected]> > > wrote: > > > Am Donnerstag, den 22.04.2010, 01:36 -0400 schrieb Alex Deucher: > > >> On Mon, Apr 19, 2010 at 4:25 AM, Uwe Bugla <[email protected]> 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 _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
