[1241] in linux-scsi channel archive
aic7xxx - buggy?
daemon@ATHENA.MIT.EDU (Alan Brown)
Thu Jan 9 02:08:36 1997
To: submit-linux-dev-scsi@ratatosk.yggdrasil.com
From: alan@news.manawatu.gen.nz (Alan Brown)
Date: 9 Jan 1997 19:40:20 +1300
Ever since the aic7xxx revisions of 2.0.13 and onwards, I've been unable
to have my news server run stably for more that about 20 hours.
I put this down to the thing being a Slackware 2.2 build originally and
having been upgraded in increments to current specs (latest libraries, etc
etc etc).
Fdisk complains that the partition tables for the scsi disks are bogus
too, so I'd made plans to back everything up and repartition/reformat,
plus update the AHA2940 firmware.
However, over the last 3-4 weeks I've been getting asked questions about
stability by various news admins who are having toruble keeping their
machines running.
The common factor: They're all running aic7xxx controllers and have
recently updated their machines to a kernel later than 2.0.13 (or have
recently built the box and installed 2.0.27 in 6 cases).
This points the finger squarely back at the adaptec code. It appears that
it's unstable on truely busy server(*). I've asked about this a few times
here and in linux.dev.kernel with little response.
Right now my only real choice is to replace the controller with a Buslogic
or EATA card, but that's not fixing the problem.
I can't believe that the aic7xxx code maintainers are disinterested in
these problems, but there's been very little discussion of it.
However, I can understand someone walking away from development when faced
with Adaptec's consistent "we do not support Linux" attitude - one which
has led me to tell customers wanting to build a Linux system to avoid
their hardware. I'd like to know if that's the case so I know what to do
about my existing hardware.
(*) "busy" = On my server, the spool records > 5 writes per second on
average, along with 2-3 writes/second on other disks and
around 50-60 reads per second. These are _averages_ - peaks
are considerably higher.
AB
--
o Stamp out unauthorised relay-hosting. This SMTP "feature" shouldn't default
"on" - See http://www.vix.com/spam/ and http://www.sendmail.org/antispam.html
o Junk email returned, in bulk, back to sender; w/copies to all postmasters.
o Received junkmail constitutes a request for aggressive site security probing.
