2010/4/25 Michel Dänzer <[email protected]>: > 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.
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 > _______________________________________________ > [email protected]: X.Org support > Archives: http://lists.freedesktop.org/archives/xorg > Info: http://lists.freedesktop.org/mailman/listinfo/xorg _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
