nv problems on FreeBSD 6.1-RELEASE for AMD64

[Chris Radlinski]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg/attachments/20070122/fa6874a9/attachment.html>