nv problems on FreeBSD 6.1-RELEASE for AMD64

[Chris Radlinski]

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:

> 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: 
> 
> > 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 at suse.de>      __        __   __
> > Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
> > Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de
> 
> 
> 
> ______________________________________________________________________
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20070125/370c2616/attachment.html>