🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.next.hardware
Article #1498

Re: SCSI Treatment

#1498
From: Scott Turner
Date: Thu, 07 Jan 1993 08:18
73 lines
4287 bytes
In article <1992Dec29.102014.25245@mic.ucla.edu> iwelch@agsm.ucla.edu (Ivo  
Welch) writes:
|> Summary:    [1]  Although  a number of   people  suggested powering down,   
Sam
|> Goldberger told me that the  SCSI bus is silent in  the ROM monitor.  
(Powering
|> down is actually  inconvenient   for me,  because I  have    auto-startup  
set;
|> unfortunately, NeXT software does not distinguish between a controlled power
|> down and a pull-plug power down, and always restarts itself.)
Sam is right. When NeXTen enter the ROM monitor the SCSI buss goes idle. All
buss drivers turn off and it is quite safe to short pins together by
connecting or dis-connecting devices. You will often get activity from SCSI
devices when you fool around with the buss in this mode. When you break the
chain and then remake it many devices will "see" a SCSI buss reset and will
perform their reset functions. Tapes drives can often be rather noisy, and
thus startling, but nothing bad is happening. The NeXT itself will command a
couple of these SCSI buss resets during booting (and will perform them when
devices timeout on the buss during operation.)


I've used a switched power outlet to get around those times when my NeXT
won't power down (wether from the auto-power on feature or from a swapper
lock up.)

|> [2]  Everyone suggested I should power  down  hard-disks first;  for one,  
they
|> set or signal their SCSI ID at power on.
Fujitsu hard disks, and others (Micropolis and Maxtor come to mind), look at
the SCSI ID jumpers ALL THE TIME. You can change them at any time, no power
cycling is required. Which is good since the worst thing you can do to your
hard disk is turn it on. :)

There are devices though that get weird. My Archive Python insists on being
power cycled before it will come back on the SCSI buss if it was set to
the same SCSI ID as some other device. You can reset the other device to
another SCSI ID, but until you actually cycle power to the Python it won't
respond to it's SCSI ID.

I suggest learning what your devices want and going from there.

|> [3]  Everyone  suggested powering down hard  disks before moving them,  
because
|> most disks have special head storage zones.
Hard disks, part of the fun here is in how rapidly this technology has changed.
Only 10 years ago I was going bonkers for a 10mb Seagate ST-412 drive, the
biggest 5.25" hard disk in the known universe. Drives from this era were made
of eggshells by comparision to the drives we have today. Some people haven't
caught up.

"Modern" discs employ chromed surfaces that are harder than the heads
themselves (the surface is as hard as that of a steak knife.) The heads have
gotten smaller, lighter, tougher, and stiffer. They are harder to tip and
several drive makers brag about operating their drives for months with the tops
off (thus letting in all sorts of trash that would kill a ST-412-era drive.)
I'm told that failures due to head disk contact are now extremely rare. In my
own experience I've never seen one since '86. Most failuers these days are
things like failures to start or some electronic failure.

Even today though, it is easier to damage a hard disk drive while it is running
for one very simple reason, while it is spinning there is more energy available
to do damage than when the disk isn't spinning. While the disk does indeed
create an air cushion under the head, it is possible to cause the head to tip
in which case the air stream supplies plenty of energy to grind the head into
the platter (although again, this is getting harder and harder to do, as the
drives get faster the head struts must get stiffer and stiffer since moving
the heads fast enough to make a 14ms drive causes enough force to tip a
ST-412-era drive strut...)

I only turn my SCSI devices off when I move them (and then only if they're
spinning.)

Scotty
Technical Details
Message-ID: <1993Jan7.081833.12054@gagetalker.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!psinntp!l5next!scotty
References: <1992Dec29.102014.25245@mic.ucla.edu>

Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.next.hardware
Path: arc1-ca.pugleaf.net!sparky!uunet!psinntp!l5next!scotty
From: scotty@gagetalker.com (Scott Turner)
Subject: Re: SCSI Treatment
Message-ID: <1993Jan7.081833.12054@gagetalker.com>
Sender: scotty@gagetalker.com
Organization: L5 Computing
References: <1992Dec29.102014.25245@mic.ucla.edu>
Date: Thu, 7 Jan 1993 08:18:33 GMT
Lines: 73