Date: Thu, 28 May 1998 22:16:01 -0700 From: Mike Smith <mike@smith.net.au> To: tcobb <tcobb@staff.circle.net> Cc: "'freebsd-current@freebsd.org'" <freebsd-current@FreeBSD.ORG> Subject: Re: DPT driver fails and panics with Degraded Array Message-ID: <199805290516.WAA00405@antipodes.cdrom.com> In-Reply-To: Your message of "Thu, 28 May 1998 23:54:49 EDT." <509A2986E5C5D111B7DD0060082F32A402FAC3@freya.circle.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > HISTORY > > > I've used DPT in FreeBSD since last November, first with the hacked > > > 2.2.2 driver. I upgraded to 2.2.6 to fix a MBUF leak that > > was crashing > > > me about once per week. As 2.2.6, the MBUF leak disappeared and was > > > replaced with a once every 2-3 day panic which it appeared > > was not going > > > to get fixed by anyone (bidone: buffer not busy). So, I > > bit the bullet > > > and upgraded recently to 3.0, which seemed to fix both of > > these prior > > > panics only to reveal that the supposedly "high > > availability" software > > > driver for my HA hardware is miserable during the most > > critical times. > > > > Given that biodone is only called from disk drivers, and I > > guess you're > > probably only using the DPT driver, it sounds like your two problems > > are one. > > > > Certainly, given that 3.0 upgrade was taken against the > > indicators, it's > > hard to feel that many of your accusations are terribly justifiable. > > Excuse me? Could you please explain what you mean by "taken against the > indicators"? In your message, the only problems that you describe are ones that are not likely to be remedied in any significant fashion. On the other hand, the risks involved in moving to a bleeding-edge development release are very substantial, as you have discovered. > It was clear from talking to more than one person on the core team that > the biodone issues were unlikely to get resolved in -stable. It would have been useful to make this discussion public. -stable is meant to be our "production quality" release, and if these problems are not isolated to a particular driver (in your case they may), then I would imagine that many people would like some accountability attached to the decision not to resolve them. > This, plus > deficiencies in the -stable NFS code (and other > -stable instabilities) caused me to have to upgrade this machine to > -current in order to keep using FreeBSD for it. I was quite reluctant > to do this, believe me. But it was the best recommendation I was given. NFS is being addressed in both -current and -stable. You could probably obtain the services of a FreeBSD-savvy consultant to bring any remedies back from -current to -stable for significantly less than the cost of the downtime and aggravation you are currently experiencing. > My problem report (most of which you snipped) pointed out a deficiency > in the DPT driver code which renders it useless in HA applications. I > believe that this deficiency is likely to be present in ALL VERSIONS of > this code, unless suddenly, people are putting the newest code in the > oldest versions of the OS. I understood this entirely. I had assumed that you would be pursuing the matter with the driver author and maintainers, and merely added that your biodone problem was quite possibly related as an additional datapoint. Neither I nor FreeBSD Test Labs nor anyone that I can manipulate have access to any DPT hardware in order to attempt to resolve your problem, so I have nothing further constructive to offer, sorry. > "Indicators" are that I shouldn't be using FreeBSD for any High > Availability or critical operations -- I AM using FreeBSD for > 15 live > servers. It does sound like you've found some serious problems, yes. Are all 15 systems exploding on a daily basis? > Now, what was your point? Rushing to the "latest and greatest" is a stupid idea, particularly when it is plastered with black and yellow striped signs. Resolving the problems that you are specifically encountering in a generally stable (and static) branch limits your risk exposure, and greatly raises your chances of success. Any investment in such a resolution will have a far longer life insofar as it is less likely to be obsoleted or defeated by other substantial changes. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199805290516.WAA00405>