nv problems on FreeBSD 6.1-RELEASE for AMD64
radlinskic at acm.org
Thu Jan 25 07:48:51 PST 2007
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?
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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xorg