[3765] in linux-scsi channel archive
AWRE/ARRE settings question.
daemon@ATHENA.MIT.EDU (Steve Thompson)
Fri Apr 24 23:02:41 1998
To: linux-scsi@vger.rutgers.edu
Date: Fri, 24 Apr 1998 22:35:58 -0400
From: Steve Thompson <stevet@myofb.org>
I have a number of SCSI devices in operation, and I have been messing with the
scsiinfo utility. I also was stupid enough to print out the X3.131
specification on my bubblejet... In any event, I have noticed an odd
discrepancy between the Error Recovery Page settings on my Micropolis drives
which doesn't make sense when compared to, say a Barracuda:
Host: scsi0 Channel: 00 Id: 04 Lun: 00
Vendor: SEAGATE Model: ST32550N Rev: 8303
Type: Direct-Access ANSI SCSI revision: 02
Data from Error Recovery Page
-----------------------------
AWRE 1
ARRE 1
TB 0
RC 0
EER 0
PER 0
DTE 0
DCR 0
Read Retry Count 40
Correction Span 48
Head Offset Count 0
Data Strobe Offset Count 0
Write Retry Count 3
Recovery Time Limit 65535
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: MICROP Model: 4345WS Rev: PM18
Type: Direct-Access ANSI SCSI revision: 02
Data from Error Recovery Page
-----------------------------
AWRE 0
ARRE 0
TB 0
RC 0
EER 0
PER 0
DTE 0
DCR 0
Read Retry Count 30
Correction Span 0
Head Offset Count 0
Data Strobe Offset Count 0
Write Retry Count 30
Recovery Time Limit 0
Now, I would be inclined to simply set the AWRE and ARRE bits on the Tomahawk
and the other drive (a 4221) and be done with it. However, I don't know if
Micropolis has done anything wierd with their firmware that would cause this
setting to interact badly with the normal operation. OTOH, the fact that
these bits are zero could indicate severe brain-damage on the part of
Micropolis. Needless to say, I can't call up Micropolis and ask them if
there's a good reason for this.
Does anyone have a good reason for _not_ setting these bits on the two drives?
If the changes work on the drives in my personal system, I'll likely feel
inclined to change the settings on the ten or so 4221s and 3243s that we
bought a few years ago.
Similarly, do I gain anything by messing with the retry counts, and the like?
One would assume that setting a higher read retry count would enable a higher
percentage of recoveries on marginal blocks, although I realize that the
difference between 32 and 255 retry attempts isn't likely to have as great an
impact as the difference between 4 and 32 retry attempts. Lowering the write
retry count seems like a good plan, if the AWRE bit is set, which is what the
Seagate looks to be doing. The Quantum drives in my system are set to
equivalent read/write retry counts, so perhaps they would benefit from a
lowered write-retry count. In fact, my TM-2100S has the EER bit set to one
which would seem to indicate that it has been instructed to perform
error-recovery procedures that are slightly risky.
The overall question raised here seems to be, how true to the SCSI
specification are these devices? Will changing the various settings interact
badly with the firmware code, perhaps enabling code-paths that are less-well
tested than the manufacturer defaults? It has certainly been my experience
that the drive manufacturers are churning out buggy firmware in so-called
production releases, so I wonder if I am simply begging for trouble by
experimenting in this way. The spare drives I have to experiment on are
mostly SCSI I CCS devices, success with which will hardly translate to
confidence in messing with modern SCSI II and III drives.
Lastly, would there be a percentage in modifying the mid-level SCSI layer to
report recovered errors via printk? Having this kind of information in the
system logs would be useful if one wanted to be informed about the possible
impending failure of a device. Getting specific devices to do this seems as
simple as setting the PER bit in the Error Recovery page -- I may set this on
one of my non-critical drives once I have a better understanding of the Big
SCSI Picture. I don't yet know if the mid-level code (or the low-level
drivers) would tolerate the Check Condition messages that would be generated.
Regards,
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
