<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.0.9"> </HEAD> <BODY> I experimented with some of the "XaaNo*" options. XaaNoSolidHorVertLine + XaaNoPixmapCache + XaaNoOffScreenPixmaps still gave me lockups. XaaNoScreenToScreenCopy worked but screen redraws were achingly slow. So far, "Option 'ShadowFB'" offers me the best compromise between performance and stability. My card is a PCI Express x16 Biostar V6202EL16 GeForce 6200 LE. Are there any nVidia-based PCI Express x16 cards out there that work perfectly with the "nv" driver? Chris On Mon, 2007-01-22 at 22:27, Chris Radlinski wrote: <BLOCKQUOTE TYPE=CITE> It sounds like you've wrestled with this problem before. Given the lack of documentation, I'm amazed at what you guys have done with this driver. You're truly gifted coders. I will experiment with the "XaaNo*" options and report my experiences. Thanks for your help. Chris On Mon, 2007-01-22 at 06:21, Matthias Hopf wrote: <BLOCKQUOTE TYPE=CITE> <PRE>On Jan 17, 07 22:43:39 -0600, Chris Radlinski wrote: > I am able to get a stack trace. The call to NVSync() that locks the > system comes from somewhere in libxaa.so. The particular function Again, this backtrace doesn't help. It only shows which graphics command wasn't able to be put into the queue - but in the queue there are already a bunch of commands which are waiting for the offending one to finish. It would be necessary to find the offending one, to see whether the parameters are correct etc. As NVidia doesn't publish specs, this is almost impossible for us to do anyway. I already tried to restart the graphics engine (modulo the commands that are already in the queue) - so one would only have some graphics glitches, but not a stalled system. So far I had no luck in doing this. The engine just doesn't start again. I tried the obvious approach (KickDMA) and some more, no luck. As it *does* start again if you restart the Xserver, it probably *is* possible, though. That might be an interesting approach for you if you want to try this out (maybe you have more success in that than I had): if the queue doesn't have an empty slot for - say - 100ms, restart the engine. > I do have a workaround. If I set "Options ShadowFB" in xorg.conf, I can > run the nv driver at reasonable speeds and without problems. I don't > know what I'm giving up by doing that but it seems to work OK. A better workaround would be to try all the "XaaNo*" options as described in "man xorg.conf" - I guess there is only one you have to specify in order to get the system running again. For some of these the impact is pretty low. But if it happens to be XaaNoScreenToScreenCopy you have bad luck, because that is about the most important one. We sometimes had good success with XaaNoSolidHorVertLine and/or with XaaNoPixmapCache and XaaNoOffscreenPixmaps. > > > I'm not sure what that means. Do I have a bad card? > > Possibly. Often cards hang here if they are broken. Still possible. Even if it works with Gentoo, they probably have a different driver version, which results in different acceleration functions being used. Matthias -- Matthias Hopf <mhopf@suse.de> __ __ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ mat@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R & D <A HREF="http://www.mshopf.de">www.mshopf.de</A></PRE> </BLOCKQUOTE> <HR> <PRE>_______________________________________________ xorg mailing list xorg@lists.freedesktop.org <A HREF="http://lists.freedesktop.org/mailman/listinfo/xorg">http://lists.freedesktop.org/mailman/listinfo/xorg</A></PRE> </BLOCKQUOTE> </BODY> </HTML>