Date: Wed, 10 Oct 2007 16:46:49 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: danfe@freebsd.org, current@freebsd.org, Craig Boston <cb@severious.net> Subject: Re: Patch for nvidia-driver on current (panic: spin locks can only use msleep_spin) Message-ID: <200710101646.50012.jhb@freebsd.org> In-Reply-To: <20071002204850.GA33227@nowhere> References: <20070921202523.GB4044@nowhere> <20071002204850.GA33227@nowhere>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 02 October 2007 04:48:57 pm Craig Boston wrote: > Hi all, I did some more investigating and found what was causing the > nvidia driver to occasionally panic on my machine. It calls cv_wait(9) > using a spin mutex, which according to the man page is a no-no. > > I simply changed the os_*_sema interfaces to use a standard mutex > instead. Tried running a bunch of glxgears and xscreensaver GL demos in > parallel and haven't been able to reproduce a panic since. As a bonus, > the 5 second pause I would sometimes get when a GL-based xscreensaver > process terminates seems to be gone as well. > > There doesn't appear to be any documentation that I could find as to > what contexts those functions may be called from. I'm not a locking > guru, so I can't say for certain why a spin mutex was being used. Wild > guess: an artifact from the 4.x or 5.x code that may be obsoleted by > adaptive mutexes. > > Patch is attached; cc danfe@ in case others report this problem to him. Your patch is good, and I think nvidia is going to fix their driver to use a regular mutex as well. It probably uses a spin mutex because on other OS's you have to use a spin mutex to protect data shared with an interrupt handler. However, in the case of FreeBSD, you only use a spin mutex if you use an INTR_FAST/filter handler, and can use a regular mutex otherwise. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200710101646.50012.jhb>