Date: Wed, 3 Jun 1998 12:54:43 +0930 From: Greg Lehey <grog@lemis.com> To: shimon@simon-shapiro.org, Mike Smith <mike@smith.net.au> Cc: Karl Pielorz <kpielorz@tdx.co.uk>, tcobb <tcobb@staff.circle.net>, "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>, Michael Hancock <michaelh@cet.co.jp> Subject: Re: DPT driver fails and panics with Degraded Array Message-ID: <19980603125443.K22406@freebie.lemis.com> In-Reply-To: <XFMail.980601205151.shimon@simon-shapiro.org>; from Simon Shapiro on Mon, Jun 01, 1998 at 08:51:51PM -0400 References: <199805292208.PAA01191@dingo.cdrom.com> <XFMail.980601205151.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 June 1998 at 20:51:51 -0400, Simon Shapiro wrote: > On 29-May-98 Mike Smith wrote: > >>> I am routinely running a Dual DPT with 38 drives on 6 busses. On >>> 3.0-CURRENT SMP. The system did lose disk drives, either >>> intentionally, or by accident. I cannot confirm any of Mr. Cobb's >>> finding. I have not been funished with any data, including the >>> panic point, which I suspect is not in the DPT code. I am still >>> waiting for such data. >> >> I'd just like to point out that the "biodone: buffer not busy" panic >> doesn't come from the DPT driver, but may be caused by it calling >> biodone() on a buffer that the system does not believe is busy. Why would a driver call biodone on a buffer that doens't belong to it? >> These situations are worth analysing, and I hope to see you and Troy >> resolving this one, even if it means that you point the finger >> elsewhere. Definitely. I'm surprised nobody has done it yet. > I got these particularly with tape devices. Especially if there are two > tape drives on the system and yoy try to (for example) cpio to both > independently. I put a ton of debugging code in the DPT driver to try and > catch the DPT sending biodone twice on the same request and am pretty > comfortable the driver is not it. OK, where is the failing biodone called from? > Especially when the st.c peripheral driver will do it almost > consistently, and the disks will almost never do that. Since the > DPT driver does not know a disk from a cucamber, I doubt it is at > fault. But any persistent test cases are very welcome. I find this difficult to follow. Onn the one hand, lots of people (myself included) regularly use the st driver, and I've never seen this behaviour. About the only thing that these panics have in common is the DPT driver. It's easy enough to determine which driver is involved: all you need to do is follow the stack trace to find what devices is involved with the buffer (or just look at bp->b_dev). Greg -- See complete headers for address and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980603125443.K22406>