From: jag@decvax.DEC.COM (John A. Gallant UEG)
Newsgroups: comp.unix.ultrix
Subject: Re: SCSI/CAM problems
Date: 8 Sep 92 16:04:10 GMT
Reply-To: jag@zk3.dec.com
Organization: OSF Engineering, Digital Equipment Corp.

In article <ROBM.92Sep4150116@ataraxia.Berkeley.EDU>, robm@ataraxia.Berkeley.EDU (Rob McNicholas) writes:

>I've recently installed the Open SCSI/CAM software on my DECstation,
[lines deleted]
>System: DEC5000/125, Ultrix 4.2C

    Is this the CAM kit out of the "product" box or a field test version ?

>	scsi bus#0: one RZ57
>                    one RRD42
>		    two EXB-8200 8mm drives Mountain Filesafe 2100D (Rev 252X)
>
>	scsi bus#1: two RZ57s
>		    one TZK50
>                    one EXB-8200 (same as above)

>This particular error given in the example was caused by using the
>public domain "copytape" program, by David S. Hayes.  The program
>aborts in a read() with an ENOSPC error (the actual error output is:
>"copytape: can't read input: I/O error").  This is consistenly
>reproducible from any tape drive.  Now we can't make duplicates of our
>backups anymore :-( I saw a note in the CAM release notes that
>mentioned a problem with model 100 machines returning the wrong number
>of bytes on odd-byte tranfers.  Could this be related?  The code looks
>like it's doing the right thing (checking the return value of the
>read() call for the actual number of bytes tranferred).

    With the backup numbers 126b is an even value.  The bug in the 100/25/240
machine is that an extra byte is transfered in but the correct number of
bytes is returned from the call.

>I should point out that we can still read this tape "dd ibs=126b
>if=/dev/nrmtNh | zcat | restore if -".

    Do you get similar CAM errors with the dd command ?

>Anyone having similar experiences?  Anyone have any suggestions?
>
>If I decide to back out on this "upgrade", will I have to reinstall
>the 4.2A kernel config files?  (I'd hate to have to do that since I've
>since installed a bunch of patches.)

    During the installation of the CAMBIN42* subsets, the non-CAM only
files are saved as *.nocam.  You would only have to compare/diff these
files.  Off the top of my head I think that there are only about 6 or 7.

>Thanks for any help, and apologies for the length of this message.

    I for one want to get this to work.  We have spent a lot of engineering
time and effort to make this new subsystem.

    How often do the error occur, on initial open ?, some where in the
middle ?, or usually at the end ?

    What is the boot string text reported by the tape driver.  If your
tape drive is not one of the DEC supported devices, ie has the DEC name in
it, there may not be an entry for it in the /usr/sys/data/cam_data.c file.
The default TZxx entry is used, for devices that fall through the table
lookup.

    What /dev/*rm* name did you use for the device.  Is it possible that
the tape may have been written in a block mode and the reads are trying
variable ?

    You may want to make sure that you have an entry in the cam_data.c file
for your device, you will want to make it look "a lot" like the TZK09 :-).

>uerf reports these errors as:

    [Not worth looking at.]

>cam_report gives this more verbose, but just as incomprehensible (to
>me) output:

    But this is where all the "meat" is. :-)

>    Sequence number of error: 8
>    Time of error entry: Fri Sep  4 14:01:30 1992

>    SCSI device class: TAPE
>    Bus Number: 1
>    Target number: 1 Lun Number: 0

    This error is comming from the tape on the PMAZ-AA card, the second SCSI
bus, with the lone Exabyte.

>    Routine Name: ctape_iodone
>    Routine Error Message: Hard Error Detected
>    Device Name: EXABYTE EXB-8200
>    Routine Message: Active CCB at time of error
>    Routine Message: CCB request completed with an error

    A "CCB" is the command/SCSI I/O Data structure used to communicate
between the device drivers and the SCSI Interface Module, (SIM).  The
CAM tape driver has received an error from the tape drive that has
terminated this I/O request.

>    CAM subsystem status ................. cam_status: 0xc4 (CCB request completed w
>    ith an error)

    The CCB has completed, and the error information has been returned as 
part of the CAM autosense functionality.

>    Data transfer length .............. cam_dxfer_len: 262144 (0x40000)

    This request has a transfer length of 256 Kbytes(!) this is a little more
than the 126b (64512 bytes) indicated in your dump parameters.
    
>    SCSI device status code ......... cam_scsi_status: 0x2 (SCSI_STAT_CHECK_CONDITION)

    The SCSI status code, here signaling a check condition (a SCSI error),
is returned from the device itself.  The CAM subsystem will issue a SCSI
REQUEST SENSE command to get the error information from the device.

>    Transfer residual length .............. cam_resid: 262144

    There was NO data transfer with this command.

>    Command descriptor block bytes ....... cam_cdb_io: 8 0 4 0 0 0

    Looking at the SCSI spec under the tape section, the command is a
simple read (0x8) of 0x40000 bytes.  The Fixed bit is not set, the tape
driver is using the tape in variable length mode.

    The rest of the log report is an attempt to decode the error
information that the device returned following it's report of an
error.  Only the standard error bytes are decoded.

>		    ############### Entry End ###############
>
>    Routine Message: Error, exception, or abnormal condition
>    Routine Message: Illegal request or CDB parameter
>
>    Dumping Request Sense Data at 0x1000e278:
>    Error code ...................... : 0x0
>    Error class ..................... : 0x7
>    Information fields valid ........ : 0
>    Segment number .................. : 0x0
>    Sense Key ....................... : 0x5 (Illegal request or CDB parameter)
>    Illegal length indicator ........ : 0
>    End of medium ................... : 1
>    Tape file mark detected ......... : 0
>    Information byte 3 .............. : 0x0
>    Information byte 2 .............. : 0x0
>    Information byte 1 .............. : 0x0
>    Information byte 0 .............. : 0x0
>    Additional sense length ......... : 0x12
>    Command information byte 3 ...... : 0x0
>    Command information byte 2 ...... : 0x0
>    Command information byte 1 ...... : 0x0
>    Command information byte 0 ...... : 0x0
>    Additional sense code ........... : 0x0
>    Additional sense qualifier ...... : 0x0
>    Sense Code/Qualifier Message .... : No additional sense information
>    Field replaceable unit code ..... : 0x0
>    Additional sense bytes .......... : 0x0 0x0 0x0 0x0 0x0 0x1 0x20 0x0 0x0 0x22 0xfc

    I had to dig out our 8500 manual to try and understand the rest of
these error bytes.  Looking at the std error bytes, EOM - End of Media,
has been reached.  Sense Key 0x5 is for illegal request.  From the
manual - "an illegal parameter in the CDB" ... "or that the EXB-8500 is
in the wrong mode to execute the command".  According to the manual,
Rev 001, there should be more error codes in the "Additional sense
code" and "Additional sense qualifier" but there is none.

    The rest of the bytes are manually decoded:
Additional sense bytes .......... :
		 15  16  17  18  19  20   21  22  23   24   25
		0x0 0x0 0x0 0x0 0x0 0x1 0x20 0x0 0x0 0x22 0xfc

Bytes 14:15 Are Reserved - We report 14 as the FRU code and 15 is 0x0
Bytes 16:18 Are Read/Write data error counters : 0x0 0x0 0x0
Bytes 19:21 Are Unit Sense
		20:bit 0 : FE - Formatter Error
		21:bit 5 : RSVD - Reserved
Bytes 23:25 Is the Remaining tape in 1024 byte physical blocks

Unfortunately there are no more bytes, I would to have liked to see
byte 28, the fault symptom code, but the EXB-8500 did not return it.

-- 
John A. Gallant                                jag@zk3.dec.com
Software Engineer - OSF Engineering Group
Digital Equipment Corp. (603) 881-2472

        In the common people there is no wisdom, no penetration, no
        power of judgment.
    Marcus Cicero