nv problems on FreeBSD 6.1-RELEASE for AMD64
radlinskic at acm.org
Mon Jan 22 20:27:58 PST 2007
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.
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
> 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 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...
More information about the xorg