home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / ultrix / 6762 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  8.1 KB
  1. Path: sparky!uunet!olivea!decwrl!deccrl!news.crl.dec.com!rdg.dec.com!decvax.dec.com!decvax.DEC.COM!jag
  2. From: jag@decvax.DEC.COM (John A. Gallant UEG)
  3. Newsgroups: comp.unix.ultrix
  4. Subject: Re: SCSI/CAM problems
  5. Message-ID: <1992Sep8.160410.17336@decvax.dec.com>
  6. Date: 8 Sep 92 16:04:10 GMT
  7. References: <ROBM.92Sep4150116@ataraxia.Berkeley.EDU>
  8. Sender: usenet@decvax.dec.com (Usenet News System)
  9. Reply-To: jag@zk3.dec.com
  10. Organization: OSF Engineering, Digital Equipment Corp.
  11. Lines: 188
  12. Nntp-Posting-Host: witsend.zk3.dec.com
  13.  
  14. In article <ROBM.92Sep4150116@ataraxia.Berkeley.EDU>, robm@ataraxia.Berkeley.EDU (Rob McNicholas) writes:
  15.  
  16. >I've recently installed the Open SCSI/CAM software on my DECstation,
  17. [lines deleted]
  18. >System: DEC5000/125, Ultrix 4.2C
  19.  
  20.     Is this the CAM kit out of the "product" box or a field test version ?
  21.  
  22. >    scsi bus#0: one RZ57
  23. >                    one RRD42
  24. >            two EXB-8200 8mm drives Mountain Filesafe 2100D (Rev 252X)
  25. >
  26. >    scsi bus#1: two RZ57s
  27. >            one TZK50
  28. >                    one EXB-8200 (same as above)
  29.  
  30. >This particular error given in the example was caused by using the
  31. >public domain "copytape" program, by David S. Hayes.  The program
  32. >aborts in a read() with an ENOSPC error (the actual error output is:
  33. >"copytape: can't read input: I/O error").  This is consistenly
  34. >reproducible from any tape drive.  Now we can't make duplicates of our
  35. >backups anymore :-( I saw a note in the CAM release notes that
  36. >mentioned a problem with model 100 machines returning the wrong number
  37. >of bytes on odd-byte tranfers.  Could this be related?  The code looks
  38. >like it's doing the right thing (checking the return value of the
  39. >read() call for the actual number of bytes tranferred).
  40.  
  41.     With the backup numbers 126b is an even value.  The bug in the 100/25/240
  42. machine is that an extra byte is transfered in but the correct number of
  43. bytes is returned from the call.
  44.  
  45. >I should point out that we can still read this tape "dd ibs=126b
  46. >if=/dev/nrmtNh | zcat | restore if -".
  47.  
  48.     Do you get similar CAM errors with the dd command ?
  49.  
  50. >Anyone having similar experiences?  Anyone have any suggestions?
  51. >
  52. >If I decide to back out on this "upgrade", will I have to reinstall
  53. >the 4.2A kernel config files?  (I'd hate to have to do that since I've
  54. >since installed a bunch of patches.)
  55.  
  56.     During the installation of the CAMBIN42* subsets, the non-CAM only
  57. files are saved as *.nocam.  You would only have to compare/diff these
  58. files.  Off the top of my head I think that there are only about 6 or 7.
  59.  
  60. >Thanks for any help, and apologies for the length of this message.
  61.  
  62.     I for one want to get this to work.  We have spent a lot of engineering
  63. time and effort to make this new subsystem.
  64.  
  65.     How often do the error occur, on initial open ?, some where in the
  66. middle ?, or usually at the end ?
  67.  
  68.     What is the boot string text reported by the tape driver.  If your
  69. tape drive is not one of the DEC supported devices, ie has the DEC name in
  70. it, there may not be an entry for it in the /usr/sys/data/cam_data.c file.
  71. The default TZxx entry is used, for devices that fall through the table
  72. lookup.
  73.  
  74.     What /dev/*rm* name did you use for the device.  Is it possible that
  75. the tape may have been written in a block mode and the reads are trying
  76. variable ?
  77.  
  78.     You may want to make sure that you have an entry in the cam_data.c file
  79. for your device, you will want to make it look "a lot" like the TZK09 :-).
  80.  
  81. >uerf reports these errors as:
  82.  
  83.     [Not worth looking at.]
  84.  
  85. >cam_report gives this more verbose, but just as incomprehensible (to
  86. >me) output:
  87.  
  88.     But this is where all the "meat" is. :-)
  89.  
  90. >    Sequence number of error: 8
  91. >    Time of error entry: Fri Sep  4 14:01:30 1992
  92.  
  93. >    SCSI device class: TAPE
  94. >    Bus Number: 1
  95. >    Target number: 1 Lun Number: 0
  96.  
  97.     This error is comming from the tape on the PMAZ-AA card, the second SCSI
  98. bus, with the lone Exabyte.
  99.  
  100. >    Routine Name: ctape_iodone
  101. >    Routine Error Message: Hard Error Detected
  102. >    Device Name: EXABYTE EXB-8200
  103. >    Routine Message: Active CCB at time of error
  104. >    Routine Message: CCB request completed with an error
  105.  
  106.     A "CCB" is the command/SCSI I/O Data structure used to communicate
  107. between the device drivers and the SCSI Interface Module, (SIM).  The
  108. CAM tape driver has received an error from the tape drive that has
  109. terminated this I/O request.
  110.  
  111. >    CAM subsystem status ................. cam_status: 0xc4 (CCB request completed w
  112. >    ith an error)
  113.  
  114.     The CCB has completed, and the error information has been returned as 
  115. part of the CAM autosense functionality.
  116.  
  117. >    Data transfer length .............. cam_dxfer_len: 262144 (0x40000)
  118.  
  119.     This request has a transfer length of 256 Kbytes(!) this is a little more
  120. than the 126b (64512 bytes) indicated in your dump parameters.
  121.     
  122. >    SCSI device status code ......... cam_scsi_status: 0x2 (SCSI_STAT_CHECK_CONDITION)
  123.  
  124.     The SCSI status code, here signaling a check condition (a SCSI error),
  125. is returned from the device itself.  The CAM subsystem will issue a SCSI
  126. REQUEST SENSE command to get the error information from the device.
  127.  
  128. >    Transfer residual length .............. cam_resid: 262144
  129.  
  130.     There was NO data transfer with this command.
  131.  
  132. >    Command descriptor block bytes ....... cam_cdb_io: 8 0 4 0 0 0
  133.  
  134.     Looking at the SCSI spec under the tape section, the command is a
  135. simple read (0x8) of 0x40000 bytes.  The Fixed bit is not set, the tape
  136. driver is using the tape in variable length mode.
  137.  
  138.     The rest of the log report is an attempt to decode the error
  139. information that the device returned following it's report of an
  140. error.  Only the standard error bytes are decoded.
  141.  
  142. >            ############### Entry End ###############
  143. >
  144. >    Routine Message: Error, exception, or abnormal condition
  145. >    Routine Message: Illegal request or CDB parameter
  146. >
  147. >    Dumping Request Sense Data at 0x1000e278:
  148. >    Error code ...................... : 0x0
  149. >    Error class ..................... : 0x7
  150. >    Information fields valid ........ : 0
  151. >    Segment number .................. : 0x0
  152. >    Sense Key ....................... : 0x5 (Illegal request or CDB parameter)
  153. >    Illegal length indicator ........ : 0
  154. >    End of medium ................... : 1
  155. >    Tape file mark detected ......... : 0
  156. >    Information byte 3 .............. : 0x0
  157. >    Information byte 2 .............. : 0x0
  158. >    Information byte 1 .............. : 0x0
  159. >    Information byte 0 .............. : 0x0
  160. >    Additional sense length ......... : 0x12
  161. >    Command information byte 3 ...... : 0x0
  162. >    Command information byte 2 ...... : 0x0
  163. >    Command information byte 1 ...... : 0x0
  164. >    Command information byte 0 ...... : 0x0
  165. >    Additional sense code ........... : 0x0
  166. >    Additional sense qualifier ...... : 0x0
  167. >    Sense Code/Qualifier Message .... : No additional sense information
  168. >    Field replaceable unit code ..... : 0x0
  169. >    Additional sense bytes .......... : 0x0 0x0 0x0 0x0 0x0 0x1 0x20 0x0 0x0 0x22 0xfc
  170.  
  171.     I had to dig out our 8500 manual to try and understand the rest of
  172. these error bytes.  Looking at the std error bytes, EOM - End of Media,
  173. has been reached.  Sense Key 0x5 is for illegal request.  From the
  174. manual - "an illegal parameter in the CDB" ... "or that the EXB-8500 is
  175. in the wrong mode to execute the command".  According to the manual,
  176. Rev 001, there should be more error codes in the "Additional sense
  177. code" and "Additional sense qualifier" but there is none.
  178.  
  179.     The rest of the bytes are manually decoded:
  180. Additional sense bytes .......... :
  181.          15  16  17  18  19  20   21  22  23   24   25
  182.         0x0 0x0 0x0 0x0 0x0 0x1 0x20 0x0 0x0 0x22 0xfc
  183.  
  184. Bytes 14:15 Are Reserved - We report 14 as the FRU code and 15 is 0x0
  185. Bytes 16:18 Are Read/Write data error counters : 0x0 0x0 0x0
  186. Bytes 19:21 Are Unit Sense
  187.         20:bit 0 : FE - Formatter Error
  188.         21:bit 5 : RSVD - Reserved
  189. Bytes 23:25 Is the Remaining tape in 1024 byte physical blocks
  190.  
  191. Unfortunately there are no more bytes, I would to have liked to see
  192. byte 28, the fault symptom code, but the EXB-8500 did not return it.
  193.  
  194. -- 
  195. John A. Gallant                                jag@zk3.dec.com
  196. Software Engineer - OSF Engineering Group
  197. Digital Equipment Corp. (603) 881-2472
  198.  
  199.         In the common people there is no wisdom, no penetration, no
  200.         power of judgment.
  201.     Marcus Cicero
  202.