From owner-cvs-all Mon Sep 11 1:37:22 2000 Delivered-To: cvs-all@freebsd.org Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by hub.freebsd.org (Postfix) with ESMTP id 5079837B43E; Mon, 11 Sep 2000 01:37:17 -0700 (PDT) Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 13YP5X-000Law-0B; Mon, 11 Sep 2000 08:37:15 +0000 Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA02551; Mon, 11 Sep 2000 09:37:57 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Mon, 11 Sep 2000 09:37:32 +0100 (BST) From: Doug Rabson To: John Baldwin Cc: Doug Rabson , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha interrupt.c In-Reply-To: <200009110036.RAA28683@pike.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 10 Sep 2000, John Baldwin wrote: > Doug Rabson wrote: > > dfr 2000/09/10 08:39:23 PDT > > > > Modified files: > > sys/alpha/alpha interrupt.c > > Log: > > Remove the manipulation of the Giant mutex from the interrupt entry > > points. This can't work right anyway and needs to happen in the irq thread. > > Err, when I tried these commented out before the big commit, the machine > panic'd after 5 minutes of uptime. Turning these on allowed it to finish a > 3 hour buildworld. Until we have working interrupt threads it may be best to > leave these in. I had exactly the opposite experience. With the the mtx_enter/exit(&Giant) calls in interrupt.c, my test box couldn't even complete a 'cvs update' without panicing. After I removed them, I managed a complete 'make world' with no incident. All the panics I saw were the same, with the machine trying to release a mutex which was already unowned. Always, the call to interrupt() was the most recent to take/release the mutex. There might be a race condition in mtx_enter because it always seemed as if the mtx_enter() from interrupt() did not correctly recurse the mutex but behaved as if it thought the mutex was unowned. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 20 8348 3944 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message