From owner-freebsd-current@FreeBSD.ORG Tue Oct 2 20:48:59 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EB9F16A46B for ; Tue, 2 Oct 2007 20:48:59 +0000 (UTC) (envelope-from cb@severious.net) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.freebsd.org (Postfix) with ESMTP id 6036613C46E for ; Tue, 2 Oct 2007 20:48:59 +0000 (UTC) (envelope-from cb@severious.net) Received: by ion.gank.org (Postfix, from userid 1001) id EB6B41121C; Tue, 2 Oct 2007 15:48:58 -0500 (CDT) Date: Tue, 2 Oct 2007 15:48:57 -0500 From: Craig Boston To: current@freebsd.org Message-ID: <20071002204850.GA33227@nowhere> Mail-Followup-To: Craig Boston , current@freebsd.org, danfe@FreeBSD.org References: <20070921202523.GB4044@nowhere> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="H1spWtNR+x+ondvy" Content-Disposition: inline In-Reply-To: <20070921202523.GB4044@nowhere> User-Agent: Mutt/1.4.2.3i X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: danfe@FreeBSD.org Subject: Patch for nvidia-driver on current (panic: spin locks can only use msleep_spin) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2007 20:48:59 -0000 --H1spWtNR+x+ondvy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. Craig --H1spWtNR+x+ondvy--