Re: New nvidia drivers available

On Sunday 15 August 2004 16:59, Stefan Ehmann wrote:
> On Sun, 2004-08-15 at 17:29, Doug Rabson wrote:
> > On Sunday 15 August 2004 16:12, Stefan Ehmann wrote:
> > > On Sun, 2004-08-15 at 11:24, Doug Rabson wrote:
> > > > On Sunday 15 August 2004 09:39, Stefan Ehmann wrote:
> > > > > On Sun, 2004-08-15 at 02:56, Johan Pettersson wrote:
> > > > > > On Sat, 14 Aug 2004 19:34:24 +0100
> > > > > >
> > > > > > Doug Rabson <dfr_at_nlsystems.com> wrote:
> > > > > > > The latest 6113 build of the nvidia graphics drivers has
> > > > > > > just appeared
> > >
> > > ...
> > >
> > > > > > Im running the new driver on a recent -CURRENT and xorg
> > > > > > 6.7.0. When starting zsnes I get this:
> > > > > >
> > > > > > beard ~> zsnes
> > > > > > Fatal error 'Exceeded maximum lock level' at line 261 in
> > > > > > file /usr/src/lib/libpthread/thread/thr_cancel.c (errno =
> > > > > > 0) Bus error (core dumped)
> > > > > > beard ~>
> > > > >
> > > > > Same error message here when starting neverball. If I map
> > > > > libpthread->libc_r it's working again.
> > > > >
> > > > > xawtv also stopped working. Fortunately setting -xvport
> > > > > manually did fix that.
> > > >
> > > > This might be because libGL calls libpthread's version of
> > > > open() before libpthread has initialised properly. This patch
> > > > might fix it - it fixes neverball's map compiler for me but I
> > > > haven't actually run neverball itself.
> > >
> > > That fixed the problem, thanks.
> > >
> > > Just noticed that libthr seems to have similiar problems. Here's
> > > a backtrace when starting neverball using libthr.
> >
> > This patch ought to fix libthr (I haven't tested it).
>
> Not quite. No segfault any more but neverball (or any GL app)
> immediately exits returning 1 immediately after startup.

Interesting. That sounds like a bug I tracked down where libGL was using 
a 'pthread_once_t' structure which didn't match the libthr (and 
libpthread) ABI. Something to do with linuxthreads compatibility. Can 
you tell me if it dies shortly after a call to pthread_once() with a 
structure containing a non-zero mutex pointer?