home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / sysv386 / 12610 < prev    next >
Encoding:
Text File  |  1992-07-29  |  3.2 KB  |  62 lines
  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!infonode!xanth.b11.ingr.com!richard
  3. From: richard@xanth.b11.ingr.com (Richard Griffiths)
  4. Subject: Re: Archive Viper 525 and Dell
  5. Message-ID: <1992Jul29.213646.28863@infonode.ingr.com>
  6. Sender: usenet@infonode.ingr.com (Usenet Administrator)
  7. Reply-To: richard@xanth.b11.ingr.com
  8. Organization: Intergraph Corporation, Huntsville, AL
  9. References: <1992Jul28.025909.7068@thunder.mcrcim.mcgill.edu> <Bs55tB.6EI@zeus.dialix.oz.au>
  10. Date: Wed, 29 Jul 1992 21:36:46 GMT
  11. Lines: 49
  12.  
  13. In article <Bs55tB.6EI@zeus.dialix.oz.au>, peter@zeus.dialix.oz.au (Peter Wemm) writes:
  14. |> bruno@thunder.mcrcim.mcgill.edu (Bruno Hall) writes:
  15. |> 
  16. |> >I am trying to get Dell SVR4 2.1 to talk to an Archive Viper 525.  
  17. |> 
  18. |> >Has anyone managed to do this?  
  19. |> 
  20. |> >At the moment, it'll write a tape file at the beginnig of a tape, and
  21. |> >then refuse to write another after the first.  Also, the light on the
  22. |> >drive stays on after the initial access -- until the tape is removed.
  23. |> 
  24. |> Whew!  For a while there, I thought I was the only person having
  25. |> problems with the 525 on Dell.  My problems are MUCH worse than yours though,
  26. |> I cannot even write (there's a blocksize problem somewhere..).
  27. |> If I write with a blocksize of 20K (the blocksize is irrelevant- i have tried
  28. |> every different one I could think of), a program I set up to debug
  29. |> the thing says "write failed: could only write 10240 of 20480 bytes".
  30. |> Reads are similar:  If I read 20K blocks, the read says it read 20K, but in
  31. |> actual fact only put 10K in the buffer.  No matter the blocksize, it
  32. |> is always out by 50%.
  33. |> My Viper 2150S Drive works fine.
  34. |> I have no idea why it does this, but I am getting annoyed enough to start
  35. |> "hacking".  I have though of putting a wrapper around the st01read and
  36. |> st01write to double and halve the block counts as appropriate - any reason
  37. |> this wont work?
  38. |> Also, the drive *floods* the SCSI bus *much* more than the 150 drive..
  39. |> (Yes, I have tried all sorts of combinations of the jumpers...)
  40. |> 
  41. |> Anybody else seen this?
  42. |> 
  43. The Archive 525 I have installed on my Esix 4.04a system works great! 
  44. (apologies to Larry and the Dellevangelists, I just couldn't resist).  
  45. The reason it works great is I modified the driver for the folks at Esix so 
  46. the damn thing would work.  Archive screwed up the auto density select.  
  47. The USL scsi tape drivers check the min/max block length returned by the drive 
  48. to decide if they are working with fixed or variable block lengths.  If you 
  49. use anything other than a 565mb tape you can only write to it in fixed block 
  50. mode (512 bytes, we're talking hardware level here not cpio/tar).  The Archive 
  51. drive always returns the maximum block length the drive is capable of 
  52. regardless of the tape media installed.  Stupid.  That means the tape driver
  53. will assume variable block lengths when the media is incapable of it.
  54. By the way, make sure your rom level on the Archive is at least 7.  Prior to 
  55. that auto density did not work at all.
  56.  
  57.  
  58. -- 
  59. Richard A. Griffiths              ...uunet!ingr!b11!xanth!richard   (UUCP)
  60. Intergraph Corp.                  richard@b11.ingr.com          (Internet)
  61. "Something's happening here but you don't know what it is. Do you, Mr. Jones."
  62.