I wrote:
We have had a rash of problems relating to 9GB Micropolis drives
(1991-27MZ) on our DU3.0B 2100 system. We keep getting "timeout on
disconnected request" CAM errors, which then causes SCSI abort and bus
reset. The errors *seem* to move with the drives as we move them to
another SCSI bus, but two drives that we moved to another host altogether
have been working perfectly ever since. The other host is a DU3.2D 2100.
Has anyone had similar problems using these drives, or am I barking
up the wrong tree?
Summary:
Turns out that we had two out of five drives replaced (3 months ago
and another last week) that were installed w/o removing term-packs
(breaking in a new Sys Admin). This clears up our recent rash of problems,
and explains why a random move of two of these five worked on the other
machine. However, looks like these drives are not a great bet in the long
run, as many replied, and as our experience in having replaced two has
already confirmed. We ordered a StorageWorks RAID system to replace them
all. Anybody interested in 5 9G drives, w/ enclosures, cheap?
Thanks to:
Gyula Szokoly <szgyula_at_skysrv.Pha.Jhu.EDU>
Tim W. Janes <janes_at_signal.dra.hmg.gb>
Patrick O'Brien <pobrien_at_draco.harvard.edu>
David Warren <warren_at_atmos.washington.edu>
Kurt Watkins <watkins_at_hhmi.swmed.edu>
Mahendra Vallabh (Mike) <mike_at_lucy.cs.waikato.ac.nz>
Dr. Tom Blinn <tpb_at_zk3.dec.com>
Bob Burchfield <bcb_at_Auspex.Com>
who answered respectively:
> Stupid idea: did you remove the terminator resistors on the drive?
Not so stupid idea!
--------
> We had very similar problems with one of these drives on a full ( 7
> device) SCSI bus on a 3000/600. I put another SCSI controller in the system
> and connected the Micropolis by itself to this controller and had no problems.
>
> 3 weeks ago I moved this drive to an Alphaserver 1000 and put it
> externally with a couple of other drives, as the cables were quite
> long I set the transfer rate top slow and have not had any problems.
>
> Our drive reports itself as
> rz6 at scsi0 bus 0 target 6 lun 0
> _(MICROP 1991-27MZ Q4D HT02)
>
> My guess is that it is sensitive to lead lengths, termination etc.
---------
> I've had fine luck (so far) with Micropolis 9GB's on an AXP3000/300.
>
> On the 2100, I've had problems with CAM errors on the RZ29B's.
>
> Both systems are running DU 3.2B.
----------
> We've had an inordinate number of them die on us. They also seem to get
> more file system problems than any other drive we have. The resellers,
> however, tell us that these do great it is the Seahates that the have
> problems with. So in our latest request for bid we decided to go for two
> four gigs instead. By the way we have trouble with them on both DEC and
> SUN machines.
-----------
> Similar problems on 3000/800 OpenVMS system. Firware upgrade from 27MZ to
> 27Q4D solved most of our problems.
------------
> I had the same errors with my 9GB Seagate disk. I ended up getting a new
> SCSI card for my 2000/300 (AXP 150) and all seems to be well. I found that
> when I shifted the disk to a PC all was well, but when I put it back on the
> alpha I got the CAM errors etc. once more. I am actually very scepticle
> about these large disks. Also, make sure your SCSI bus isn't too long.
> >From memory, I think the max length is (2-3 metres).
> Just some sugeestions,
-------------
> Support for "generic" SCSI disks (that is, disks for which there isn't any
> entry in /etc/disktab or data in cam_data.c) has come a LONG way since the
> V3.0B release. The fact that you're not seeing problems on V3.2D suggests
> there is nothing wrong with the drives, that the problem is either in the
> V3.0B software (possibly) or that you need to add descriptions of these 9GB
> Micropolis drives into the cam_data.c file and rebuild the kernel. I can't
> offer you any advice on what you need to specify, but the file is largely
> self-documenting and there are a number of examples there.
--------------
> We shipped a few micropolis 9 GB drives over a year ago. Turns out
> they had a manufacturing flaw that caused the coating to peel off
> after a few hundred hours of service. We had to put a stop-ship
> on them and have yet to ship a 9 GB drive. We're currently shipping
> 4 GB Seagate drives. They had a bad firmware rev recently (4609)
> that we suspect may have been caused by a new feature that pulls the
> head into the middle of the disk when it's quiescent. (Optimizes the
> next seek time -- on average.) Big rash of problems with the disks
> going offline and having to be power-cycled. We're currently running
> rev. 4611 firmware without incident.
Received on Thu May 02 1996 - 03:28:03 NZST