From owner-freebsd-current Sun Oct 29 16:54:59 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA20516 for current-outgoing; Sun, 29 Oct 1995 16:54:59 -0800 Received: from ast.com (irvine.ast.com [165.164.128.2]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA20510 for ; Sun, 29 Oct 1995 16:54:51 -0800 Received: from fw.ast.com by ast.com with SMTP id AA10212 (5.67b/IDA-1.5 for ); Sun, 29 Oct 1995 16:55:56 -0800 Received: from nemesis by fw.ast.com with uucp (Smail3.1.29.1 #4) id m0t9hnN-00008GC; Sun, 29 Oct 95 18:09 CST Received: by nemesis.lonestar.org (Smail3.1.27.1 #19) id m0t9hkn-000ItnC; Sun, 29 Oct 95 18:07 WET Message-Id: Date: Sun, 29 Oct 95 18:07 WET To: jmb@kryten.atinc.com, current@freebsd.org From: uhclem%nemesis@fw.ast.com (Frank Durda IV) Sent: Sun Oct 29 1995, 18:07:04 CST Subject: Re: WANGDAT strangeness Sender: owner-current@freebsd.org Precedence: bulk [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 |"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