Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 29 Oct 95 18:07 WET
From:      uhclem%nemesis@fw.ast.com (Frank Durda IV)
To:        jmb@kryten.atinc.com, current@freebsd.org
Subject:   Re: WANGDAT strangeness
Message-ID:  <m0t9hkn-000ItnC@nemesis.lonestar.org>

next in thread | raw e-mail | index | archive | help
[0]a WangDAT tape drive that under 2.0.5 won't let you remove the media until
[0]you reboot the system, OR you can issue a mt offline, remove the media, and
[0]then reboot to get the drive to load new media - that really stinks and

[1]	this problem must be unique to WangDAT or at least non-exabyte 
[1]4mm tape drives.   i use a 4mm for daily backup.  unload the tape with 
[1]"/usr/bin/mt -f /dev/rst0 rewoffl".   load a new tape every morning and 
[1]haev no problems at all.  

I plan to try this drive on 2.1 1026 SNAP before I file a real bug report
on it.  This is an early WangDAT DAT drive, but it is new enough to have 
compression.  It came out around late 1990 or early 1991.

FYI, the 1540A host adapter was flagged as an "unknown board" during
installation from the 2.0.5 boot floppy, but the driver seems to know what
board it is once you get running off the SCSI hard disk.  At least the
"unknown board" complaint went away.  Strange.


The DAT drive has a READY and an ACCESS light.  Under SCO, the READY light
would blink yellow while loading/unloading, then remain green until the
media is unmounted.   The ACCESS light only blinked during
commands/transfers, etc.  So when the drive is idle (tape loaded or unloaded),
the ACCESS light is dark.

On 2.0.5-R, the ACCESS light is off until you touch the drive, then it
goes on solid and remains on regardless of activity.   Once the drive is
touched, the front-panel eject button no longer works.  (From external
appearances, it acts like it is always in the middle of processing a
command from the host.)

If you issue a mt offline command, the ACCESS light goes out.  Now you
can press the front-panel EJECT button and get the media out of the
drive.  However if you try to insert any media, the READY light
just blinks YELLOW and the loader refuses to grab the tape and take
it inside.   You must reboot to load the next tape.  All of the mt commands
fail once you issue a mt offline, even if you don't remove the media.

The drive/driver also has a habit of locking up under 2.0.5.  Because of
the botched status light under 2.0.5, I can't tell what is going on with
the drive.  All I know is that the transfers appear to stop.  After five
minutes or so, I will get a timeout error from the driver, and the
application aborts.  This was a real pain as I tried to restore peoples'
account data.  I was never able to get a large blocksize (>1K) to work all
the way through the cpio or tar (I happened to make both before migrating).

Finally I used a tar with a blocksize of 1 (wow is that slow) and was able
to get all the way through without incident but it took six hours.  Of
course I then had to reboot to get the media out of the drive, but that is
another problem.

I have been using the DAT drive for about four years under SCO UNIX with
their standard driver, so I know that the drive works well.

All these failures were with reads.  I haven't tried any write operations
(I'm almost afraid to attempt something that might stress the driver
like running 'dump'), but that day is coming.   I may be forced to start
NFS, and do some sort of primitive backup of the 2.0.5 system over the
network to a SCO machine.  Yuck. 

This was certainly not one of the snags I told management we might encounter
in migration.

Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi"
or uhclem%nemesis@fw.ast.com (Fastest Route)| demand...  A SEGMENT REGISTER!!!"
...letni!rwsys!nemesis!uhclem               |"A what?"
...decvax!fw.ast.com!nemesis!uhclem         |"LETNi! LETNi! LETNi!"  - 1983




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0t9hkn-000ItnC>