Skip site navigation (1)Skip section navigation (2)
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>