Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!evax!utacfd!merch!cpe!adaptex!adaptx1!neese
From: neese@adaptx1.UUCP
Newsgroups: comp.periphs.scsi
Subject: Re: WHAT IS SCSICNTL.EXE
Message-ID: <283400075@adaptx1>
Date: 19 Mar 91 06:57:59 GMT
References: <2@lehigh.bitnet>
Lines: 54
Nf-ID: #R:lehigh.bitnet:2:adaptx1:283400075:000:2888
Nf-From: adaptx1.UUCP!neese    Mar 18 10:59:00 1991


>>>/* ---------- "WHAT IS SCSICNTL.EXE" ---------- */
>>>WHAT IS THIS PROGRAM?
>>>IS IT NEEDED IF I AM USING A SCSI DRIVE WITH A 1542B ON A PC?
>>>
>>>PLEASE REPLY TO BDS2@NS.CC.LEHIGH.EDU
>
>I don't mean to knock the scsicntl program, but use it with care!
>On a 386/25 running Esix Rev D, with a CDC Wren IV and a Toshiba MK-156FB
>drive, and an Archive 2150S, I did the following.  I shut down unix, 
>booted dos, ran scsicntl.  I selected the page that controls
>cache on the drive -- I had previously turned cache on  (long ago) --
>I now turned cache off -- (this was all on the cdc wren, the toshiba
>doesn't have cache, although it seems faster than the wren, but that's
>a different story).  When I again tried to boot Unix, it wouldnt' boot!
>
>I tried the quick recovery in Esix, but that didn't help.  It wasn't
>getting to the point where it actually loads /unix.  The machine would
>self test, see the scsi drives, blank the screen, pause a few seconds,
>and then re-initiate the self-test.
>
>A complete re-install was necessary.  (The Toshiba is the boot drive).
>I haven't had the time or inclination to re-try this operation to see
>if it was actually the scsicntl operation or some fluke.  Someday maybe
>I will, because I still want to try turning off the cache on the CDC
>again.

Uhmmm.  Whenever anyone has a problem with SCSICNTL, I would like to hear
about it.  Please Email me.  I test it with quite a few devices before I
send it out, but the problem is,....I can't know when someone has changed
firmware in a SCSI device, so something could break, and break very easily.
I am also only human and may make mistakes.  The risk is always there.  I
try to be very careful about this, but again,....  If you have a problem,
what I would like is all the information that shows up in the data box
on the left at the main menu.  I have many contacts in the SCSI industry
and could get the firmware to test with to find out what is happening.
Also please note the verion of SCSICNTL you are using.
SCSICNTL can be very dangerous and should always be used with caution.
Although, sometimes you don't know until you do it and at that point it
is too late.  Of course, a SCSI device should not allow you to get the
drive to a point that it is no longer functional.  If an invalid command
or invalid data is sent to the drive, it should just return an error and
reject the command.  But life in the real world ain't that easy.

As far as this particular incident goes.  I find it interesting.  The Wren
IV was one of the first drives I developed SCSICNTL for.  I have used it on
this drive since the drive first came out.  I am at a loss as to what
SCSICNTL could have done to cause this problem.  What version of SCSICNTL
are you using?

			Roy Neese
			Adaptec Senior SCSI Applications Engineer
			UUCP @  neese@adaptex
				uunet!cs.utexas.edu!utacfd!merch!adaptex!neese