[comp.unix.osf.osf1] Convinced OSF tape driver is broken (fwd)

From: <pat_at_krl.caltech.edu>
Date: Tue, 5 Mar 1996 08:49:30 -0800 (PST)

        A group in my lab has been having severe difficulties with
        the tape driver under both 3.2b and 3.2d. In some cases the
        tape in the drive was made on a stacker, but in one case a
        tape-to-tape dd crashed the system with a freshly made tar tape
        as the source. I think something ain't right with the Qlogic
        SCSI controller. This could be a kernel bug. -pat

Forwarded message:
>
> I have been trying to get a data analysis program that reads
> and writes from Exabyte tape working for the past two weeks with
> nothing but frustrations. I have come to the conclusion that the
> OSF tape driver is severely broken or the Qlogic controller is
> seriously flawed. We have observed the behavior below on both of
> our 600(5/266) stations with a variety of 8505/8500 drives and
> passive/active terminators. We are using the SCSI-2 (not the wide)
> port off the boxes. On box has OSF/1 v3.2D-1 and the other v3.2B.
>
> 1) The system will crash with either "kernel memory fault" or
> "Unable to restart Qlogic LUN queue after Abort!" or just
> hang the entire system forcing a hardware reboot during
> tape operations at seemingly random intervals. This is
> running the program as any user, not just root. We can
> semi-consistantly make this happen when starting our program
> immediately after putting in the tape (but still waiting for
> the drive to settle). If we use 'mt' to forward a file, start
> our program and rewind inside our program we seem to be able
> to avoid the reboot/hang (most of the time). Sometimes just the
> tape drives hang and only a system reboot will work to kill it.
>
> 2) A read() call on a tape file descriptor will always fail with
> I/O error if you give it a buffer size > 64k. Doing this will
> sometimes put the drive in a strange state where even forward
> and backward space file operations give you an error. If the
> device has a maximum 64k record limit, I can understand why a
> write() should fail, but the read should not care its buffer
> is bigger than it needs.
>
> 3) We bought three 8505 drives through DEC. After turning on a
> tape drive and then powering up the computer (which I have
> go first to HALT mode prompt), I do a 'show dev' and the
> tape drive does not show up. Wait 2 minutes and do another
> 'show dev' and it finally appears. Our 8500 drives (from
> third parties) always show up immediately.
>
> I know everyone's first statement is "termination". I have
> checked the tape drives to see if they have internal
> termination and they do not. I have tried at least six
> different external terminators of both the active and
> passive variety. I have tried five different drives (three
> 8505's from DEC, and two third party 8500's).
>
> Our data tapes were written with the 8500 drives on an AIX machine
> at high density (5GB/tape).
>
> Paul Raines
> ------- End of forwarded message -------
>
Received on Tue Mar 05 1996 - 18:12:54 NZDT

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:46 NZDT