[comp.unix.sysv386] BIG problem with 1542B and Quantum disks

tmanos@wyvern.uucp (Tom Manos) (05/09/91)

Hello netters,

I need help in a big way.

I've started having problems with my UNIX system since I installed an
Adaptec AHA-1542B and two Quantum SCSI disks: a ProDrive 210S and a ProDrive
105S, both internal.  I'm running with the following h/w & s/w:
Zeos 386/20, 8MB RAM, no coprocessor, generic VGA card.
Microport SysV/386 r3.2.2 with the Columbia Data Products driver set.

I'm experiencing the following symptoms:

When both drives are installed and mounted doing:
find <drive1> -depth -print | cpio -pd > <drive2>
will hang the system after a random but small number of copies.  The disks
will seem to slow down for a few seconds, until they come to a complete halt
from which there is no return save the reset button.  The second disk is
totally unusable. As long as I'm only accessing one disk, everything works.

When only the 210S is mounted, the system will run, but disk throughput
seems slow, and when there is intense disk activity (like when news is being
processed), keyboard response is agonizingly slow while waiting for the
disk.  Sometimes it takes more than a minute for a response.  Also, even
with only one drive mounted, I've noticed that when using the floppy
(with cpio for instance), the floppy head will do wierd seeks, like it got
a read error and is retrying, when there is SCSI disk activity.  I'm
running the floppy off the 1542B. 

The AHA-1542B is configured as follows:
SCSI id 7
Synchronous transfer enabled
SCSI parity enabled
DMA channel 5
DMA request 5
DMA acknowledge 5
Interrupt channel 11
DMA speed 5MB/s
Adaptec bios enabled
bios base addr DC00
auto sense enabled

The drives are configured as SCSI id 0 & 1, with parity enabled.  I've got
terminators on the 1542B and the farthest drive from the card (the 105S).

Can anyone tell me what my problem could be?  Microport can't.  Alliance
Peripheral Systems (my retailer) can't.  I've got a 105MB doorstop right
now that I need to make useful.

Please help!
Thanks!

Tom  (tmanos@wyvern or ...!uunet!xanth!wyvern!tmanos)
-- 
Tom Manos      Norfolk, VA      tmanos@wyvern       (...!xanth!wyvern!tmanos)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
I gotta get away from this day to day running around.
Everybody knows this is nowhere.  - Neil Young

pa@curly.appmag.com (Pierre Asselin) (05/10/91)

In article <1991May9.002915.262@wyvern.uucp>
tmanos@wyvern.uucp (Tom Manos) writes:
>I've started having problems with my UNIX system since I installed an
>Adaptec AHA-1542B and two Quantum SCSI disks: a ProDrive 210S and a ProDrive
>105S, both internal.  [...]
       ^^^^^^^^^^^^^

Here goes nothing:  my own "internal" 105S came with terminating
resistors.  Look for SIP's on the PC board just above the SCSI
connector.  Try wiring one drive at an unterminated end of the bus.

As long as I'm here, should I even *think* of removing the drive's
terminating resistors?  I hate to fix something that ain't broke,
but I'd like to do things right.  Tom will have to do something
(maybe).  Is trading-in the drives his only option?

--Pierre Asselin, R&D, Applied Magnetics Corp.  I speak for me.

abc@rock.concert.net (Alan Clegg) (05/10/91)

In article <1991May9.002915.262@wyvern.uucp> tmanos@wyvern.uucp (Tom Manos) writes:
. When both drives are installed and mounted doing:
. find <drive1> -depth -print | cpio -pd > <drive2>
. will hang the system after a random but small number of copies.  The disks
. will seem to slow down for a few seconds, until they come to a complete halt
. from which there is no return save the reset button.  The second disk is
. totally unusable. As long as I'm only accessing one disk, everything works.

Are you saying that the drives actually spin down?  If so, you may not have
a large enough power supply in your machine.

[Stupid suggestion, but, who knows...]

-abc
-- 
"this is a hellacious hairball and we  | Alan Clegg - Network Programmer
 need to start by acknowledging that   | MCNC -- Center for Communications
 everybody can't get what they want"   | Research Triangle Park, NC, USA
[ Paul Vixie, on RFC-822 Extensions ]  | abc@concert.net, abc@mcnc.org

manos@wisteria.cs.odu.edu (Tom Manos) (05/11/91)

In article <1991May10.140925.7452@rock.concert.net> abc@rock.concert.net (Alan Clegg) writes:
>In article <1991May9.002915.262@wyvern.uucp> tmanos@wyvern.uucp (Tom Manos) writes:
>. When both drives are installed and mounted doing:
>. find <drive1> -depth -print | cpio -pd > <drive2>
>. will hang the system after a random but small number of copies.  The disks
>. will seem to slow down for a few seconds, until they come to a complete halt
>. from which there is no return save the reset button.  The second disk is
>. totally unusable. As long as I'm only accessing one disk, everything works.
>
>Are you saying that the drives actually spin down?  If so, you may not have
>a large enough power supply in your machine.
>
>[Stupid suggestion, but, who knows...]

Not a stupid suggestion, I just didn't make myself clear.  The drives don't
spin down, but disk I/O slows to a standstill.  Not immediately, but over
the space of 10 seconds or so.

I still haven't gotten any useful suggestions on what is wrong here...
Anybody???

Tom (tmanos@wyvern  or ...!uunet!xanth!wyvern!tmanos)

rmk@rmkhome.UUCP (Rick Kelly) (05/12/91)

In article <1991May9.002915.262@wyvern.uucp> tmanos@wyvern.uucp (Tom Manos) writes:
>
>Hello netters,
>
>I need help in a big way.
>
>I've started having problems with my UNIX system since I installed an
>Adaptec AHA-1542B and two Quantum SCSI disks: a ProDrive 210S and a ProDrive
>105S, both internal.  I'm running with the following h/w & s/w:
>Zeos 386/20, 8MB RAM, no coprocessor, generic VGA card.
>Microport SysV/386 r3.2.2 with the Columbia Data Products driver set.
>
>I'm experiencing the following symptoms:
>
>When both drives are installed and mounted doing:
>find <drive1> -depth -print | cpio -pd > <drive2>
>will hang the system after a random but small number of copies.  The disks
>will seem to slow down for a few seconds, until they come to a complete halt
>from which there is no return save the reset button.  The second disk is
>totally unusable. As long as I'm only accessing one disk, everything works.
>
>When only the 210S is mounted, the system will run, but disk throughput
>seems slow, and when there is intense disk activity (like when news is being
>processed), keyboard response is agonizingly slow while waiting for the
>disk.  Sometimes it takes more than a minute for a response.  Also, even
>with only one drive mounted, I've noticed that when using the floppy
>(with cpio for instance), the floppy head will do wierd seeks, like it got
>a read error and is retrying, when there is SCSI disk activity.  I'm
>running the floppy off the 1542B. 
>
>The AHA-1542B is configured as follows:
>SCSI id 7
>Synchronous transfer enabled
>SCSI parity enabled
>DMA channel 5
>DMA request 5
>DMA acknowledge 5
>Interrupt channel 11
>DMA speed 5MB/s
>Adaptec bios enabled
>bios base addr DC00
>auto sense enabled
>
>The drives are configured as SCSI id 0 & 1, with parity enabled.  I've got
>terminators on the 1542B and the farthest drive from the card (the 105S).
>
>Can anyone tell me what my problem could be?  Microport can't.  Alliance
>Peripheral Systems (my retailer) can't.  I've got a 105MB doorstop right
>now that I need to make useful.
>
>Please help!
>Thanks!

Try pulling the Synchronous Transfer jumper and see if it makes a difference.
Your drives may not have the MODESELECT set for RESELECTION, which could cause
the trouble you are seeing.

I'm running two Quantum PRO-80s on an Adaptec 1540A with no problem.

Rick Kelly	rmk@rmkhome.UUCP	frog!rmkhome!rmk	rmk@frog.UUCP

rwhite@jagat.uucp (Robert White) (05/13/91)

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@jagat           <Home |  not directly related to my job off of my
rwhite@nusdecs         <Work |  employers machine.  Please use "jagat"
"Like most endevors, life is seriously over-advertised and under-funded"