aic7xxx Rev 6.3.5 problems/questions.

[Todd Denniston]

Tom Hansen wrote:
> 
> Hello,
> 
> I am writing in reference to the following post:
> 
> On Wed, Feb 25, 2004 at 04:16:13PM -0500, Todd Denniston wrote:
> > "Justin T. Gibbs" wrote:
> 
> > > This is because the Promise controllers do not provide an echo buffer.
> > > In the past, the driver would just fail DV and complain about the
> > > broken device.  Since the promise controllers were all developed long
> > > after having an echo buffer was a requirement, they should support it.
> > > I believe that their latest firmware does.
> >
> > unfortunately this is the latest firmware for the RM8000, so I guess they
> > still don't "get it" on all their development lines.
> 
> They apparently don't always have the latest on their web site.  We had
> a promise for a short while, and our IT guy got the latest firmware, it
> still didn't work, then he called them, they sent him another that was
> much more recent, and did work.
> 
> a
> 
> We are currently experiencing this problem, and I'm trying to get this "much
> more recent" firmware that you are talking about.  The most recent currently
> on their web site is 1.1.0.30 which is dated Feb 4, 2004.  Given that your
> post was dated Feb 25th, I''m wondering if this Feb 4th firmware is already
> the one you are talking about, or if in fact there is a more recent one.
> 
> I just got off the line with Promise tech support.  They told me that the
> 1.1.0.30 is their most recent firmware.  Further, they are suggesting that
> it is a bug in the aic7xxx driver and that I should contact Adaptec.
> 
1.1.0.30 is the latest thing I have been able to get a hold of, and I would
_suggest_ installing it as it made the boxes *MUCH* more stable ... but still
not fully stable.

as for the "DV failed to configure" my bet is that they have not implemented
domain validation that is required of Ultra SCSI 160 devices[1]&[2].  If they
have then there are two other options 1) the did not implement it to the
specification, or 2) the DV in the Adaptec code for Linux/BSD is not
implemented to the specification.

I am still running 6.3.5 of the Adaptec driver[3] because when I tried to
upgrade to a later kernel+6.3.6driver the scsi sub system fell apart. I need
to divide and conquer to figure out whether it was the kernel or the driver
update that failed (both at the same time is not a good Idea).

with 6.3.5 I have found that if I disable DV then my problems are reduced,
that is, the box will run for more than 20 days with out problems where as
with DV it will fail in under 48 hours.

for me in modules.conf:
#no options would run for ~48 hours.
#following line runs for 20+days
options aic7xxx aic7xxx=verbose.global_tag_depth:224.dv:{0}
#next line crashes system in < 24 hours
#options aic7xxx aic7xxx=verbose.global_tag_depth:212.periodic_otag
#next line would run for ~5 days.
#options aic7xxx aic7xxx=verbose.global_tag_depth:1

Promise suggested that I reduce the bus speed (what DV should do if it was
working [1]), I set the bus (use the ctrl-A at boot to get into the adaptec
card) to 40MHz, and the box has now been up for just over 18 days.
Goal: 80.000MB/s transfers (40.000MHz DT, offset 62, 16bit)
Granted I could only push ~25MB/s to the Promise device when it was set to
160MB/s, so the current speed is still more than the Promise box can do.

of course... just as I wrote this the promise box locked up AGAIN!!!


[1] http://www.storagereview.com/guide2000/ref/hdd/if/scsi/protDomain.html

[2] Ultra SCSI 160 is Listed as a Hardware feature and System Requirement on
page 70 of the promise 
"User's Manual" 
Version 8.0 Rev. A
P/N:C61010000000001 (C)2002 Promise Technology, Inc

[3] http://people.freebsd.org/~gibbs/linux/
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter