HELP

[Doug Ledford]

Mike Bilow wrote:

> I won't quote back too much of your message, but I think the above is enough to
> keep us on the track.
> 
> My basic thesis is that the tape drive motors are pulling down the +12 VDC line
> and causing the drive's fail-safe sensors to cut in.  There are likely
> inductive spikes floating all over the place as a result, and some of them
> could be reaching the bus.  If this happens, it will appear as if the SCSI bus
> just goes away intermittently, affecting all of the connected peripherals
> including the hard drive.  In a well designed system, the hard drive will
> behave as if it is repeatedly recovering from  a "loose cable" problem, and you
> will see data overruns, underruns, aborted commands, and even bus resets.

That's a possibility. Agreed.  However, the reason I didn't think of that as
a first teir possibility is because I also see the overrun errors on heavily
loaded systems that are using nothing but hard disks and should be
experiencing these spikes.  They are most commonly associated with Quantum
Flakyball drives, but Seagate Medalist drives will as well on occasion and I
suspect that the Conner hard drives are probably in the same class as the
Medalist drives from Seagate.  Now, if I only had a SCSI bus analyzer and
could start tracking on this..... :)  Maybe I should just ship Justin a
preconfigured system complete that exhibits the problem and have him hook it
up :)  I suspect it's related to a load/store data pointers operation on an
already active SCB that then gets swapped out of the controller and back in,
but I haven't figured it out just by looking at the code.  The fact that it
only effects the lower classes of SCSI drives almost makes me wonder if it
might be that we are doing things right, but those lower quality drives have
firmware glitches that only show up when their queue is full....Seagate
Barracudas and Quantum Atlas I drives are immune to this problem for
instance.
 
> That's my error: I misread the PUN.  In any case, the point is that the bus is
> going away for brief intervals and then coming back, and this is causing
> aborted commands after timeouts.  The fact that the condition never reached a
> bus reset, as you point out, is an indication that burst noise is causing
> interference on the bus, and I strongly suspect that the source of that burst
> noise is motor spikes from the tape drive.

If it is burst noise, then yes, this makes sense and is a possibility :)  I
guess this goes back to one's experience.  I've never had a tape drive that
does what you mention in terms of power usage and cutouts, but I've had many
a bad tape, so I assume that to be the cause first :)
 
> Many of the lower RPM drives use +5 VDC for even the spindle these days.  The
> reason is that it results in much lower power dissipation at the motor speed
> controller.  You still need +12 VDC for the higher RPM drives, and the more
> expensive drives still do this because it is more reliable.  The trade-off is
> that you get greater range of control with higher voltage, but the power
> dissipation varies as the square of the voltage drop through the regulator, and
> the resulting thermal penalty is very severe.

I'll take you rword for it, as the slowest drives I have is a 4500 RPM
Quantum Fireball and 3600 RPM (I think) Seagate Medalist drives.  Both note
that they require 12V, but unlike my other drives, they don't list the
current draw at each voltage so I can tell if it's actually being used for
something like a motor.  On the other hand, my Barracudas are quite
obviously 12V motors judging by the current ratings at each voltage level :)
 
> Well, yes, there is certainly the possibility that the tape jam sensors are
> being set off by a real tape jam!  If we failed to make that clear, we should
> have.  I just assumed that this happened in more than an isolated case.

I start at the easiest explanation and work to the harder ones when reports
come in, it usually saves me considerable time :)
 
> The voltage regulation is not a matter of pure tolerance.  The power supply has
> some given amount of current capacity.  If this is exceeded, then either the
> power supply will completely shut down (in the case of a more expensive power
> supply) or the voltage will go below tolerance.

True.  My statements about when a spindle will usually spin down were based
on an older P66 system built about 2 years ago that was having drive spin
down problems, so we hooked up a recording voltmeter to the power supply and
found out that when the bottom dropped to 11.1 or 11.2 volts then the drive
spun down.  Other power supplies will do as you mention and simply shut off.
 
> To give an example, I had an HP Netserver -- certainly no cheap machine --
> configured with two 5.25-inch HH Seagate hard drives and an Archive Python, and
> the machine would consistently shut down during the power-up sequence.  With
> only two hard drives and one tape drive, the tape drive had to be reconfigured
> (by disabling its power-on self-check) in order to allow the machine to boot at
> all.  With a higher quality power supply as was in an NP Netserver, it was
> possible to be confident that the voltage would be stable once started as long
> as the machine did not actually shut down.  With a lower quality power supply,
> the voltage would have just swung out of tolerance.

Or, I suppose you could have used delayed spindle starts and had the OS spin
up the drives :)  Linux will do this, just configure your SCSI drives not to
spin up at bootup, and configure the controller not to send the start unit
command.  Then, when the linux OS is ready to read the partition table, it
will spin the drives up one at a time for you as it reads each table.  Since
it waits for a drive to spin up before reading its table and moving on to
the next, you get a slower boot process, but it's easier on the power
supply.
 

>  DL>   Opinions expressed are my own, but
>  DL>      they should be everybody's.
> 
> :-)

I wanted a nice arrogant sounding sig :)

-- 

 Doug Ledford  <dledford at dialnet.net>
  Opinions expressed are my own, but
     they should be everybody's.

To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message