🚀 go-pugleaf

In article <1992Apr10.083059.14733@terminator.cc.umich.edu>  
danno@css.itd.umich.edu (Daniel T. Pritts) writes:
|> In article <1992Apr7.210116.1048@helical.com> rallan@helical.com writes:
|> >Leaving a device off throughout the session should not be a problem --  
unless it is the  
|> >LAST device, which should be the ONLY one terminated. For reasons best  
explained by an  
|> >EE, some of these terminators require power to operate correctly.
|> >
|> 
|> This is not always true.  I have had scsi chains that would not work  
properly
|> unless ll the devices were turned on.  not just the last one.  
|> 
|> I never bothered to diagnose it further, and don't really know why either...
|> but i guess i'd say, if you don't have any visible problems when you leave
|> things turned off, then you probabl don't have anything to worry about.
|> Then again, i'm not an EE and could be all wet and your system might
|> blow up of you do this.  ;)
The terminator power can come from the SCSI buss, supplied by the host machine,
or from the device itself. Some SCSI devices allow you to select the method
of powering the terminator. There will be a shunt that allows you to select
local or buss power to the terminator.

If the terminator power is supplied from the buss then the last device on the
chain can be turned off and the buss will STILL be terminated.

Things that @#$! up the above, cables that don't pass terminator power, 
someone blows the fuse on the host and there is no power now.

As for turning devices off, I've covered this before so if it sounds like
I'm repeating myself, I am. :)

The NeXT SCSI buss drivers are *NOT* very robust. SCSI is quite capable of
having devices turned off and on. As to wether your software can handle this,
in the case of the NeXT it usually can't. The most common problem is that
when a SCSI device is powered down it goes spastic and pulls the SCSI reset
line. This fries the SCSI buss and the host software MUST recognize that this
happened and then act as if IT had pulled the reset ie re-config the buss
etc. SCSI devices can also yank other lines when they go spastic, they can
look as if they want to talk to the NeXT and then disappear. If the NeXT
doesn't time out properly then the SCSI buss will lock up. Spastic devices
can also jump into the middle of a transfer and @#$! it up. And if the NeXT
doesn't have code to recognize this and deal with it then it will lock up.

Basically it's all NeXT's fault if your machine locks up because you power
cycled an attached SCSI device. I've used properly coded SCSI hosts, take
the WD7000 code for SVR4 as an excellent example. I've turned devices off/on,
pulled the terminator off and then put it back on, I've added devices, taken
devices out ie broken the cable chain. It *IS* possible to create this code.

Until such time as NeXT gets it's SCSI act together, make sure nothing is
happening on your SCSI buss when you turn things off/on. This will give you
the best shot possible of not confusing the NeXT SCSI driver. But keep in
mind that if you have a removable media device on the buss, and it has no
media mounted in it, the NeXT will be polling it every few seconds to see if
media has been inserted. So make sure you put something in it so the NeXT
will stop polling. Examples: CD-ROM drives, flopticals, Syquest's. Tape drives
don't get mounted so they don't get polled. So they don't count.

Scotty