home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / sun / hardware / 5505 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  2.8 KB
  1. Xref: sparky comp.sys.sun.hardware:5505 comp.periphs:1507
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!sun-barr!cs.utexas.edu!uwm.edu!ogicse!das-news.harvard.edu!husc-news.harvard.edu!burrhus!ddl
  3. From: ddl@burrhus.harvard.edu (Dan Lanciani)
  4. Newsgroups: comp.sys.sun.hardware,comp.periphs
  5. Subject: interesting tape interaction
  6. Message-ID: <1992Nov12.013140.21432@burrhus.harvard.edu>
  7. Date: 12 Nov 92 01:31:40 GMT
  8. Article-I.D.: burrhus.1992Nov12.013140.21432
  9. Followup-To: comp.sys.sun.hardware
  10. Organization: Harvard University, Cambridge, MA
  11. Lines: 38
  12.  
  13.  
  14.     I observed an interesting problem the other day and, though
  15. it may be related to partial faults in some of the components involved
  16. (and while it certainly depends on a specific combination of components),
  17. a description might possibly save somebody some time.  My configuration
  18. consists of a Sun 3/260 with a Xylogics 472 controlling a CDC (Keystone?)
  19. 9-track 1600/6250 bpi drive using the buffered Pertec interface running
  20. at 500kBps.
  21.     Having a file which was just a little too large to fit on one tape
  22. at 1600 bpi with a 20k record size, I decided to try a 40k block.  The write
  23. operation failed with (according to the error code) a data-late condition.
  24. This didn't seem totally unreasonable since I don't know the 472's sustainable
  25. data rate and 500kBps might be marginal depending on the exact buffering/DMA
  26. interactions.
  27.     I decided to check into this in detail later but switch to 6250bpi
  28. for the current tape.  However, upon starting the copy, I noticed that the
  29. drive was doing an unreasonable amount of repositioning and remained near
  30. BOT.  Soon the Sun timed out and aborted the copy, but the drive continued
  31. to thrash.  Eventually the drive stopped but the Sun was clearly confused
  32. and would not allow further access to the device.  Thinking that the
  33. driver might have been confused from the original data-late condition,
  34. I power-cycled everything and started over.  Same result.  I repeated
  35. this a couple of times.
  36.     At this point I was beginning to worry that something had happened
  37. to the drive or controller and I ran some diagnostics on the drive.  All
  38. seemed fine.  And after the diagnostics (which, important point, write
  39. on the tape) the copy from the Sun worked.  To make a long story short
  40. (yes, I know, too late) the CDC drive behaves very oddly when trying
  41. to write at 6250bpi to a tape with a long 1600bpi record size.  I don't
  42. know if the process would eventually succeed, because the Sun gives up
  43. too soon.  I do know that first overwriting with a short 1600bpi record
  44. avoids the problem.  I also note that the thrashing looks suspiciously
  45. like the drive's normal auto-density-on-read-determination sequence,
  46. even flashing the density light once or twice.  Why it would be doing
  47. this on a write-from-BOT is beyond me...
  48.  
  49.                 Dan Lanciani
  50.                 ddl@harvard.*
  51.