home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / sun / hardware / 6343 < prev    next >
Encoding:
Internet Message Format  |  1992-12-18  |  4.9 KB
  1. Path: sparky!uunet!mcsun!Germany.EU.net!ira.uka.de!uka!i11s10!wolpers
  2. From: wolpers@i11s10.ira.uka.de (Andreas Wolpers)
  3. Newsgroups: comp.sys.sun.hardware
  4. Subject: Problems with Fujitsu 2654SA disk and SunOs 4.1.2
  5. Date: 17 Dec 1992 22:04:54 GMT
  6. Organization: University of Karlsruhe, FRG
  7. Lines: 93
  8. Distribution: world
  9. Message-ID: <1gqti6INNjuj@iraul1.ira.uka.de>
  10. NNTP-Posting-Host: i11s10.ira.uka.de
  11. Keywords: dump, large disks
  12.  
  13. Hi folks,
  14.  
  15. last friday we installed two Fujitsu M2654SA disks (2 GByte) on two
  16. Sparstation 2 running SunOS 4.1.2. 
  17.  
  18. They were delivered together, one formatted, one unformatted.
  19. Well, I fomatted the second one with parameters taken from the first
  20. disks label, and 3600 rpm (since the label didn't specify this value
  21. and I couldn't find any information in the accompanying "literature".
  22.  
  23. Initally, both were filles with 450-490 MB of data (home directories :-( ).
  24. The increase in disk usage in the following days was minimal (both had
  25. less than 500MB when the nightmare started)
  26.  
  27. Both disks worked fine 'til Tuesday, 2am. That's when our weekly
  28. level 0 dump begins. The first disk (which came formatted) survived
  29. this event, the second failed in the middle of the process, garbled
  30. beyond recognition. I called the vendor and since they told me that
  31. this was a 5400 rpm disk, I thought it was my fault.
  32.  
  33. Until this afternoon.
  34.  
  35. We did another level 0 dump last night, and in the corresponding log file
  36. I found a message
  37.  
  38.   DUMP: (This should not happen)bread from /dev/rsd2c [block 34640]: count=8192,got=-1
  39.  
  40.  
  41. which made me a bit nervous after the crash on tuesday morning. A look at
  42. the logs of the level5 dumps in between revealed messages like
  43.  
  44.   DUMP: corrupted directory, inumber 342411
  45.  
  46. I unmounted the file system (The entire disks were used as 2GB partitions)
  47. and fsck'ed it: no errors. I dumped it to /dev/null and got lots of messages
  48. like the ones above. Another fsck found no errors.
  49.  
  50. Finally, I tried to tar the disk's contents to a tape. FUBAR!!!!!!
  51.  
  52. /var/adm/messages contains one disk related message from Dec. 15, and lots of
  53. messages from this afternoon:
  54.  
  55. Dec 15 02:11:47 ardbeg vmunix: esp0: Current command timeout for Target 2 Lun 0
  56. Dec 15 02:11:47 ardbeg vmunix: esp0:    State=UNKNOWN (0x1a), Last State=RESEL (0x1b)
  57. Dec 15 02:11:47 ardbeg vmunix: esp0:    Cmd dump for Target 2 Lun 0:
  58. Dec 15 02:11:47 ardbeg vmunix: esp0:    cdb=[ 0x8 0x5 0x7f 0xd0 0x6 0x0 0x0 0x0 0x0 0x0 ]
  59. Dec 15 02:11:47 ardbeg vmunix: sd2:    SCSI transport failed: reason 'reset': retrying command
  60. Dec 15 02:11:47 ardbeg vmunix: sd1:    SCSI transport failed: reason 'reset': retrying command
  61. Dec 15 02:11:47 ardbeg vmunix: esp0:    Target 1 now Synchronous at 4.0 mb/s max transmit rate
  62.  
  63.  
  64.  
  65. Dec 17 02:14:15 ardbeg vmunix: esp0: Current command timeout for Target 2 Lun 0
  66. Dec 17 02:14:15 ardbeg vmunix: esp0:    State=UNKNOWN (0x1a), Last State=RESEL (0x1b)
  67. Dec 17 02:14:15 ardbeg vmunix: esp0:    Cmd dump for Target 2 Lun 0:
  68. Dec 17 02:14:15 ardbeg vmunix: esp0:    cdb=[ 0x8 0x0 0x87 0x32 0xc 0x0 0x0 0x0 0x0 0x0 ]
  69. Dec 17 02:14:15 ardbeg vmunix: sd2:    SCSI transport failed: reason 'reset': retrying command
  70. Dec 17 02:14:18 ardbeg vmunix: esp0:    Target 1 now Synchronous at 4.0 mb/s max transmit rate
  71. Dec 17 02:14:18 ardbeg vmunix: esp0:    Target 1 now Synchronous at 4.0 mb/s max transmit rate
  72. Dec 17 02:14:18 ardbeg vmunix: sd2c:   Error for command 'read'
  73. Dec 17 02:14:18 ardbeg vmunix: sd2c:   Error Level: Fatal
  74. Dec 17 02:14:18 ardbeg vmunix: sd2c:   Block 34640, Absolute Block: 34640
  75. Dec 17 02:14:18 ardbeg vmunix: sd2c:   Sense Key: Hardware Error
  76. Dec 17 02:14:18 ardbeg vmunix: sd2c:   Vendor 'FUJITSU' error code: 0x15
  77.  
  78. Dec 17 15:40:57 ardbeg vmunix: esp0: Disconnected command timeout for Target 2 Lun 0
  79. Dec 17 15:40:57 ardbeg vmunix: sd2:    SCSI transport failed: reason 'timeout': retrying command
  80.  
  81.  
  82. Dec 17 16:34:08 ardbeg vmunix: esp0: Current command timeout for Target 2 Lun 0
  83. Dec 17 16:34:08 ardbeg vmunix: esp0:    State=UNKNOWN (0x1a), Last State=RESEL (0x1b)
  84. Dec 17 16:34:08 ardbeg vmunix: esp0:    Cmd dump for Target 2 Lun 0:
  85. Dec 17 16:34:08 ardbeg vmunix: esp0:    cdb=[ 0x28 0x0 0x0 0x30 0xcd 0x0 0x0 0x0 0x2 0x0 ]
  86. Dec 17 16:34:08 ardbeg vmunix: sd2:    SCSI transport failed: reason 'reset': retrying command
  87. Dec 17 16:34:08 ardbeg vmunix: sd1:    SCSI transport failed: reason 'reset': retrying command
  88. Dec 17 16:34:08 ardbeg vmunix: esp0:    Target 1 now Synchronous at 4.0 mb/s max transmit rate
  89.  
  90. Dec 17 17:02:50 ardbeg vmunix: bad block 100221746, <3>/mnt: bad block
  91.  
  92. Dec 17 21:45:25 ardbeg vmunix: sd2 at esp0 target 2 lun 0
  93. Dec 17 21:45:25 ardbeg vmunix: sd2: <Fujitsu-M2654SA cyl 2195 alt 2 hd 21 sec 87>
  94.  
  95. Any idea what's going on?
  96. Oh,btw, ardbeg has no internal drives, an external 520 MB Fujitsu 3.5 inch
  97. and the above-mentioned 2 GB drive. about 2.5 meters cable externally.
  98.  
  99.  
  100.  
  101. -- 
  102. Andreas Wolpers                University of Karlsruhe
  103. e-mail: wolpers@ira.uka.de     Institute for Logic, Complexity
  104. phone:  49-721-608-3977        and Deductive Systems
  105. fax:    49-721-697760          Karlsruhe, Germany
  106.