Date: Mon, 11 Sep 2000 09:37:32 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: John Baldwin <jhb@pike.osd.bsdi.com> Cc: Doug Rabson <dfr@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/alpha/alpha interrupt.c Message-ID: <Pine.BSF.4.21.0009110928500.49106-100000@salmon.nlsystems.com> In-Reply-To: <200009110036.RAA28683@pike.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009110928500.49106-100000>