Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!unido!tub!tmpmbx!einoed!utopia!scuzzy!src
From: src@scuzzy.in-berlin.de (Heiko Blume)
Newsgroups: comp.unix.sysv386
Subject: Re: <10127@nstar.uucp>
Message-ID: <1990Sep15.182423.6277@scuzzy.in-berlin.de>
Date: 15 Sep 90 18:24:23 GMT
References: <10127@nstar.uucp> <77900008@adaptex>
Organization: Scuzzy Research Center (SRC)
Lines: 20

neese@adaptex.UUCP writes:
>What the behavior you are describing is quite simple.  At power on a SCSI
>device goes through it's self-test.  Some SCSI devices will hold the SCSI
>bus busy during this period of time.  These devices will cause a SCSI bus
>reset to be issued by the adapter after the SCSI bus goes free so you will
>see the device go through it's self test again.
>If a OS issues a SCSI bus reset and does not wait for the bus to clear up
>before going further, there is a good chance that they will not recognize the
>device when they get to the first issuance of a SCSI command.

all too true, with my three drive combo i have to reboot after i power the
machine up (when the 'booting the blah' message comes) because the ST296
is too slow at startup - it doesn't show up the first time. i didn't had to
do this with my old board because the ram test took longer, so installing
more RAM (more than 8MB) could cure this :-)
-- 
Heiko Blume c/o Diakite   blume@scuzzy.in-berlin.de   FAX   (+49 30) 882 50 65
Kottbusser Damm 28        blume@scuzzy.mbx.sub.org    VOICE (+49 30) 691 88 93
D-1000 Berlin 61          blume@netmbx.de             TELEX 184174 intro d
scuzzy Any ACU,e 19200 6919520 ogin:--ogin: nuucp ssword: nuucp