SUMMARY:Problem with Non-Sun external SCSI drive

From: Alex Finkel (
Date: Thu May 23 1996 - 08:45:28 CDT

Thank you all for the many responses.

Original Question (Condensed):
Drive is: IBM DORS 2160 drive from APS (2 GB, 3.5", 8.3 MS seek time,
800,000 hour MTBF...)

I have attached the drive to a Sun Sparc 5 (running Solaris 2.4) which has
two 500MB internal drives, an Internal CDROM and an external 4mm DAT drive
attached. The APS/IBM drive is the only part not from Sun. I did a boot
-r, ran format
and partitioned the drive and put all 2 GB in one slice, then did a newfs
with the default options. Everything seemed to run fine. I even ran fsck
after the newfs completed to make sure it was OK.

Problem: Under moderate to heavy usage, I am seeing SCSI reset errors on
the console and the following error:

# WARNING: /iommu@0,10000000/sbus@0,10001000/espdma@5,8400000/esp@5,8800000/sd@2
,0 (sd2):
        Error for command 'write' Error Level: Retryable
        Requested Block 30148, Error Block: 30148
        Sense Key: Aborted Command
        Vendor 'IBM':
        ASC = 0x4e (overlapped commands attempted), ASCQ = 0x0, FRU = 0x0

The reset errors were not isolated to this new drive, but it seems the
obvious culprit.
My questions are:

1) Is is absolutely necessary to use SUN drives?
2) Is the drive bad, too slow, incompatible in any way?
3) Would it help if I re-ran newfs using options?
4) Is this a problem with tagged-queing?
The Answers:

Thanks to: David G. Wiseman
                Patrick O'Brien
                Karlheinz Pischk
                Amanul Haque
                Marcel Chukwunen
                Benjamin Cline
                Ken Dickey - Sr.
                Kevin Sheehan
                Bernd Schwarzkugler

The most common response was that Tagged Queueing was the culprit and to
turn it off by adding:

set scsi_options & ~0x80

in the file /etc/system. There will be a performance hit, but this is a
development box in use by 4 people so I think we can live with it. Under
heavier usage the best option would be to exchange it for another brand.

I read the part about tagged queueing in the FAQ, but it just wasn't obvious
to me. From the suggestions I got, it should be added to the FAQ that IBM
drives typically have a problem with Tagged Queueing. If it is there and I
missed it, then I apologize. One interesting tidbit, I have a Sparc 5 that
came from Sun with a 1GB IBM drive, so apparently not all IBM drives are

Most of the those responding commented that non-Sun drives in general are
not a problem and drives from just about any major manufacturer/supplier
(except IBM) work great. To be fair to IBM, I am using a nearly identical
IBM 2.0 GB drive (also from APS) on an NT 3.51 server for over a year with
no problems.

Another common suggestion was to check the length of the cables in the SCSI
chain and to check that all connectors are seated firmly. Also check for
proper termination. These are all sound procedures which I did take into
account and recommend to everyone to do proactively.

One other possiblility is that I have one or more bad blocks:
From: Karlheinz Pischke <>

you should just run a
        (select the right drive)
or if you want to make it not on the fly
back up all data
        def # defect list
        both # extract defect list
                # commit that you want to use this defect list (under SunOS)
        lab # label the disk
        for # reformat disk
newfs ...
But if you get in the next few weeks again error messages with different
blocks. Send the drive back for exchange. (or repair)
I'm going to try disabling tagged queing first before I muck with the drive
itself. APS has a 30-day no hassle return policy so if it comes to that,
its going back.

Thank you, everyone!

- Alex

 (( / \ )) | Alex Finkel       | 26 Landsdowne St.      |   Macintosh, Jr.
   /   \   | Network Manager   | University Park at MIT | 
  /     \  | PFN, Incorporated | Cambridge, MA  02139   | The power to crush
 / P F N \ |   |    |   the other kids.

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:00 CDT