--
Simon Greaves voice: (+679) 212114
Computer Centre fax: (+679) 304089
The University of the South Pacific email: greaves_s_at_usp.ac.fj
Suva, Fiji
----------------------------------------------
From: alan_at_nabeth.cxo.dec.com (Alan Rollow - Dr. File System's Home for
Wayward Inodes.)
Errors from the SCSI driver generally come in two flavors; protocol
errors and device errors. Adapter errors are much less common and
may not appear to come out of the CAM driver. Protocol errors are
usually sequences of timeouts, aborts, phase errors, etc. In a full
listing these errors won't have SCSI Request Sense data.
Devices errors do have Request Sense data. Most such errors should
be taken seriously, but you have to understand how SCSI devices
report state back to a command initiator. SCSI commands can fail
with one of a number of basic status messages; OK, Check Sense,
Busy, etc. Chapter 6 or 7 of the SCSI-2 spec has the complete
list of status codes.
The one of interest is Check Sense. This message means that the
device has information about the state of the last command. It
could mean that command failed or that the command completed with
some side affect. The basic status of the command is encoded in
three bytes returned in the Sense Data (obtained with the Request
Sense command); Sense Code, Additional Sense Code and Additional
Sense Code Qualifier. All the Sense Codes are standardized by
the SCSI-2 spec as well as many of the ASC and ASCQ values. About
half the ASC/ASCQ pairs are set aside for "Vendor Specific"
errors.
How to interpret a given error depends on the error, but the Sense
Code often gives a good clue, since of the codes is Recovered Error.
Particular to the error given, some command was sent which required
the device be "ready" and it wasn't. A example would be removable
media device getting a command that requires media; a disc in a
CDROM. Since the device type was RODIRECT (read-only direct access)
and the target id is one commonly used for CDROM, it appears that
your CDROM is empty and a command was sent to it that expected it
to be full. This was probably inconvient to the application using
the CDROM, but not particularly interesting to the system as a
whole. Now, if the CDROM has media in it, and it still isn't
ready, that's a more interesting problem.
There's plenty of other information encoded in the Request Sense
data, but you usually need fairly extensive device documentation
to know how to translate the information.
----------------------------------------------
From: "Dr. Tom Blinn, 603-884-0646" <tpb_at_doctor.zk3.dec.com>
That particular error is coming from a device of class "RODIRECT", and
seems
to be coming from bus 0, device id 4, target 0, which is usually a
CDROM; as
the "error" condition reported was "NOT READY - Logical unit is NOT
ready" I
am forced to wonder what application, if any, was attempting to force
access
to a not-ready CDROM unit.
I can imagine, for instance, that such an error would occur if you had
some
user application that was trying to access the CDROM drive directly,
which
did not interlock the CDROM unit so that the media could not be removed,
and
someone removed the media while the application was using the device.
In other words, some class of USER ERROR is causing this.
Tom
Dr. Thomas P. Blinn + UNIX Software Group + Compaq Computer Corporation
110 Spit Brook Road, MS ZKO3-2/U20 Nashua, New Hampshire 03062-2698
Technology Partnership Engineering Phone: (603) 884-0646
Internet: tpb_at_zk3.dec.com Digital's Easynet: alpha::tpb
ACM Member: tpblinn_at_acm.org PC_at_Home: tom_at_felines.mv.net
Worry kills more people than work because more people worry than work.
Keep your stick on the ice. -- Steve Smith ("Red Green")
My favorite palindrome is: Satan, oscillate my metallic sonatas.
-- Phil Agre, pagre_at_ucsd.edu
Yesterday it worked / Today it is not working / UNIX is like that
-- apologies to Margaret Segall
Opinions expressed herein are my own, and do not necessarily represent
those of my employer or anyone else, living or dead, real or imagined.
----------------------------------------------
From: Brian Leverson <brian_at_aa.washington.edu>
Simon,
I doubt that the AS800 has power-management, but we had a similar
problem with
an AS 255/233. I was unaware that the power-management feature was
spinning
down the disk after 30 minutes of inactivity. Upon receiving a read
request,
the OS did direct the drive to spin up, but the read request did not
allow
enough time for the spin-up to complete. So the CAM SCSI error was
generated.
After disabling the drive spin-down, the CAM SCSI errors went away.
Good luck,
--
Brian Leverson, Systems Manager
University of Washington e-mail: brian_at_aa.washington.edu
Dept of Aeronautics and Astronautics phone: (206)543-6736
Box 352400 FAX: (206)543-0217
Seattle, WA 98195-2400
-------------Original Question----------------
Hi,
an as800 5/400 (DU 4.0D + p2) has logged a few disk errors recently. Is
this something I should be concerned about? Is there a definitive guide
to the uerf/cam errors and their importance?
For the sake of bandwidth I've extracted some of the uerf log here,
though I'll gladly provide more if anyone is interested...
EVENT CLASS ERROR EVENT
OS EVENT TYPE 199. CAM SCSI
SEQUENCE NUMBER 57.
OPERATING SYSTEM DEC OSF/1
OCCURRED/LOGGED ON Fri Aug 28 16:35:21 1998
OCCURRED ON SYSTEM xxxx
SYSTEM ID x0007001B
SYSTYPE x00000000
----- UNIT INFORMATION -----
CLASS x0005 RODIRECT
SUBSYSTEM x0000 DISK
BUS # x0000
x0020 LUN x0
TARGET x4
----- CAM STRING -----
Active CCB at time of error
CCB request completed with an
error
ERROR - os_std, os_type = 11, std_type = 10
Error, exception, or abnormal
_condition
NOT READY - Logical unit is NOT
ready
Received on Tue Sep 08 1998 - 20:44:52 NZST
This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:38 NZDT