Date: Fri, 5 Jun 1998 09:33:49 +0930 From: Greg Lehey <grog@lemis.com> To: shimon@simon-shapiro.org Cc: Michael Hancock <michaelh@cet.co.jp>, "freebsd-current@freebsd.org" <freebsd-current@FreeBSD.ORG>, tcobb <tcobb@staff.circle.net>, Karl Pielorz <kpielorz@tdx.co.uk>, Bob Willcox <bob@luke.pmr.com>, Mike Smith <mike@smith.net.au> Subject: Re: DPT driver fails and panics with Degraded Array Message-ID: <19980605093349.K768@freebie.lemis.com> In-Reply-To: <XFMail.980604121635.shimon@simon-shapiro.org>; from Simon Shapiro on Thu, Jun 04, 1998 at 12:16:35PM -0400 References: <19980604095717.A22406@freebie.lemis.com> <XFMail.980604121635.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 June 1998 at 12:16:35 -0400, Simon Shapiro wrote: > > On 04-Jun-98 Greg Lehey wrote: > > ... > >>>> I had to put some pretty ugly validity checks in the interrupt code to >>>> prevent my driver from trying to do an iodone (AIX's version of >>>> biodone) >>>> on already completed (or purged, I don't remember for sure...its been >>>> over a year now) commands. Seems that the DPT firmware would (on >>>> occasion) interrupt with a status packet that pointed to a ccb that my >>>> driver had already completed. As I recall this would only happen under >>>> heavy load and it was pretty intermittant. As far as I know, it was >>>> never actually fixed. >>> >>> Actually, this is *extremely* relevant, if the firmware is still doing >>> it and the DPT driver isn't aware of this. >> >> This would normally cause a 'biodone: buffer already done' message, >> which is a warning, not a panic. The only way I could think of this >> happening on a valid buffer (apart from the obvious of calling it >> while it wasn't busy) would be if something messed around with other >> buffer flags. I haven't been following this thread very >> carefully--were the panics associated with SMP only? If so, how is >> mutual exclusion performed in the bottom half of SMP drivers? > > Actually this is a 2.2 (UP :-) problem. Not a 3.0, and not an SMP for sure. Good to hear. > Actually, SMP interrupt service is slow enough that this probably never has > a chance to show at all. No way. Murphy is particularly unforgiving when it comes to race conditions in interrupt handlers. Have 50 interrupts a second from two processors, and sooner or later you're going to hit it. 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?19980605093349.K768>