brooks@tazdevil.llnl.gov (Eugene D. Brooks III) (05/10/91)
On a SPARC 1 running SUNOS 4.1 we managed to use an ARCHIVE Python DAT drive in 1/4 inch streaming tape compatibility mode. The Python is 100% compatible with the ARCHIVE VIPER streamer tape, which happens to be a Sun supported drive. To support the drive we simply created a table entry in st_conf.c identical to the one for the VIPER, except that the identifier string was changed to ARCHIVE Python. We used the DAT drive in this way for about 6 months, but ran into trouble when we upgraded our SPARC 1 to a SPARC 2 which requires SUNOS 4.1.1 We noted that some work had been done to st_conf, some of the identifier strings had been changed in minor ways. We did the usual hack only to have the following error message appear on the console when we tried to use the drive: esp0: ILLEGAL bit set State=SELECT Last State=FREE Latched stat=0x12<XZERO,CD> intr=0x40<ILL> fifo 0x20 last msg out: <unknown msg 0xff>; last msg in: LINKED COMMAND COMPLETE DMA csr=0x96400210<EN,INTEN> addr=fff0000 last=fff0000 last_count=7 Cmd dump for Target 4 Lun 0: cdb=[ 0x12 0x0 0x0 0x0 0x24 0x0 ] pkt_state 0x0 pkt_flags 0x9 pkt_statistics 0x0 cmd_flags=0x5 cmd_timeout = 0 Mapped Dma Space: Base = 0x444 Count = 0x24 Transfer History: Base = 0x444 Count = 0x24 Driver then reported that several other targets were now Synchronous at 4.0 MB/s max transmit rate, as if the SCSI bus had been reset. An EXABYTE made the usual grinding noises as if the bus had been reset at the time. Is there anyone reading this list that has some experience with the 4.1.1 device driver which could shed some light on this problem? We would really like to get the DAT drive back on line, we have a lot of data on DAT tapes and not being able to read them is problematic.
datri@convex.com (Anthony A. Datri) (06/05/91)
>drive in 1/4 inch streaming tape compatibility mode. The Python is 100% >compatible with the ARCHIVE VIPER streamer tape, If that were true, then it would return a product code like "ARCHIVE VIPER". Mine returns "ARCHIVE Python 25501-xxx". >for about 6 months, but ran into trouble when we upgraded our SPARC 1 to a >SPARC 2 which requires SUNOS 4.1.1 I'm using the above Python on an SS2 right now: /* Archive python DAT */ { "Archive Python", 14, "ARCHIVE Python", ST_TYPE_ARCHIVE_DAT, 512, (ST_AUTODEN_OVERRIDE | ST_BSF), 400, 400, { 0x00, 0x00, 0x00, 0x00}, { 0, 0, 0, 0 } }, The only problem I've seen is if I do something like this: tar cf /dev/rst1 foo tar cf /dev/rst1 foo tar cf /dev/rst1 foo tar cf /dev/rst1 foo Every other command gets an I/O error, with the following to the console: st1: Error for command 'write', Error Level: 'Fatal' Block: 120504 File Number: 0 Sense Key: Media Error Vendor (Archive Python) Unique Error Code: 0x3b Putting "mt -f /dev/rst1 rew" after the tar makes the problem go away. This isn't really much of a problem, though, since it's a pretty silly thing to do to begin with. Oh yeah -- an mt reten gets /dev/rst1 retension 1 failed: Inappropriate ioctl for device but that doesn't bother me all that much either. I'm getting ~150k/sec writing to the drive with dump, which isn't bad, since the manual claims a peak rate of 183k/sec. -- Fly to the sky on GI-GI____________ and shout to datri@convex.com