BIG problem with 1542B and Quantum disks

[Robert White]

Ok, dumb question... do you have a driver written spesifically for the
SCSI board you are using?  Is it also for the UNIX Release you are using?
Using the bare minimum knowlege of SCSI and the discription of your
symptoms I came up with what follows.

Since SCSI is a interupt-response kind of deal that allows for but
does not necessarily include multiple outstanding requests (depending
on the controller logic) you could be experiencing problems with
instruction interleaving on the SCSI bus.

The multiple drive disaster formula comes into play when a software
driver is expecting a blockeing behavior our of the controller and
does not get it.  To Whit:

Driver places a request for X:A (sector A from drive X)
   and returns with no data because the SCSI system is running ASYNC.

Driver places another request for X:A and returns with data 'cause
   the previous request has returned and teh data "just happens"
   to be in place in the SCSI bus buffer.

Everybody is happy but the system is slowed down because the lower
level driver automatic retry routine is acting as a busy-wait and
is actively consuming cpu during disk activity.  The heavier the
activity the more cpu is waiusted processing interuupts that are
unnecessary.

If the driver is set to do "fair scheduling" and there is more
than one device on the bus, the model fails...

   Processor                 SCSI bus
    request                 data cache
===============          ================
      X:A                      ---
      Y:B                      X:A
      X:A                      Y:B
      Y:B                      X:A
<and so on...>

When the second device is added to the system the probability
of consicutive requests for the same data diminish as the load
reaches equal proportions across the diverse drives.

NOTE: this is a simple model of asynchronus drive scheduling
taken directly from some of my readings involving such matters
and may not accurately represent the SCSI access methods.
But it is a stock problem and it does match your symptoms.

Depending on exactly how your driver is configured in its implementation
it may be as simple as rebuilding your kernel with a couple of
parameters jiggled.  If you don't have the correct driver, and/or
the board you possess isnt one of those supported by the native
internals provided by the manufacturer you may just need to
either a)get the driver updated by the controler manufacturer,
or b) change controlers for on that is supported.
-- 
Robert C. White Jr.          |  I have moved my news reading activities
rwhite at jagat           <Home |  not directly related to my job off of my
rwhite at nusdecs         <Work |  employers machine.  Please use "jagat"
"Like most endevors, life is seriously over-advertised and under-funded"