From owner-freebsd-stable Tue Mar 9 6:44:58 1999 Delivered-To: freebsd-stable@freebsd.org Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (Postfix) with ESMTP id D437B14BDD for ; Tue, 9 Mar 1999 06:44:55 -0800 (PST) (envelope-from mike@sentex.net) Received: from leaverite (leaverite.sentex.ca [209.112.4.36]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id JAA14938; Tue, 9 Mar 1999 09:43:00 -0500 (EST) Message-Id: <3.0.5.32.19990309094658.04650a80@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 09 Mar 1999 09:46:58 -0500 To: Mark Powell , freebsd-stable@FreeBSD.ORG From: Mike Tancsa Subject: Re: 3.1-R panic In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >options "SOFTUPDATES" >pseudo-device splash Assuming its not hardware, and it doesnt sound like it, I would try getting rid of the softupdates option. From a number of people who are having panics, many have softupdates turned on. However, I know of a lot of people with softupdates, and they are running solid. Still, news is fairly disk intensive and might be triggering some deadlock somewhere. Also, the situation below might be relavant to you... At 04:35 PM 3/4/99 -0800, Matthew Dillon wrote: > The problem is a deadlock caused by the fgrep. The fgrep is mmap()ing > the file, but then it does some really weird crap when dealing with > larger files. > > It's the most idiotic code I've ever seen. The code uses a PRIVATE+RW > mmap() until it gets to odd point in the file, at which point it read()'s > additional information from the file into the mapped space ( that might > contain a previous mmap'd portion of the file ). > > So what happens is this: > > * read() call > * shared lock obtained on vnode > > ( some other process attempts to get shared lock on vnode and > succeeds... for example, a namei operation is attempted by > another grep ) > > * access MMAP'd area > * exclusive lock attempt obtained on same vnode. This blocks because > some other process has a shared lock on the vnode. > > ( the other process then attempts to get an exclusive lock on the > vnode this blocks. > > Deadlock. > > Even worse, the gnu grep does not bother munmap()'ing the space so, in > fact, the deadlock can occur between two unrelated files as well as with > the same file. This is the more likely deadlock scenario. > > The solution is more difficult. We could hack an exception for PRIVATE > mmap's... there really is no need for the vm_fault code to lock the vnode. > Howver, other situations can occur where this hack would not work. > > This is 'kinda a known problem' in FreeBSD. We really need to find a > solution to it. Other similar deadlocks can occur if you mmap() one file > and read() or write() data from it to another file, and vise versa at > the same time. > > Personally, I think the only real solution is to make vn_read() and > vn_write() lock the uio space as well as the vnode being read or > written. It would have to do it in the right order, and it would have > to deal with the situation where the uio space covers multiple vnodes. > > Alternately, vnodes need to be redesigned without these fraggin > all-encompassing locks for data R+W ops. > > -Matt > ------------------------------------------------------------------------ Mike Tancsa, tel 01.519.651.3400 Network Administrator, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message