hauke wrote:
> At 6:27 Uhr +0100 10.12.1997, Colin Wood wrote:
> >Paul Ripke wrote:
> >>
> >> Not sure if this made it to the list, so here it is again.
> >>
> >> Also, I have tried the NCRSCSI kernel - while it does not crash, it
> >> drops bytes every few 100k, stuffing the CRCs.
> >>
> >> Looks like some code somewhere can't handle the 1024k blocksize AIX
> >> uses on tapes... Fairly often (ie, 3 out of 5 times) this problem
> >> results in a hang, but the above was generated from single-user
> >> mode panic.
> >
> >Yes, this is a somewhat known problem, I believe.  We really don't support
> >non-512K media at the moment (at least not the last I heard).  There were
>  ^^^^^^^^^
>          Huh?
> This is /dev/*r*st0, right? dd(1)'s blocksize and the (ffs related)
> blocksize of a block device ate two horses of different colours, methinks...

Yes, I've always wondered about that - it *is* the raw device, afer all.

> >3 proposed solutions in the works, but the development was slowed by the
> >death of the developer.  I believe someone else has picked up where he
> >left off, but not with quite the fervor.
> >
> >I hope this clears things up a bit.
> 
> Not quite.  8)
> 
> First, I am not sure the mac68k port is too well tested with scsi tape
> drives. (Scott, Allen? ;)

Well, the tape drive I was using (a IBM badged HP) works perfectly
doing a straight "tar -cvf /dev/rst0", "tar -xvf /dev/rst0", and this
is how I recently repartitioned all the NetBSD partitions on my
machine (root, usr, home, sys/src was getting too messy :-) ).

> Second, both the behaviour of the ncrscsi driver and the sbc driver remind
> me of phenomena I have seen every now and then with another "slow" device,
> the infamous Fujitsu MO drive. The esp driver for the 53c96 is a bit more
> stable here, probably because the chip is more mature and the driver is
> largely MI. (Unfortunately, this is not an option here.)

Yes, I agree here. I see corruption with NCRSCSI on the SyQuest 200, which
is relatively slow... but the fact that NCRSCSI *almost* works to the AIX
written tape worries me.

> Last, some time ago I have toyed around with a "known bad" HP DAT drive
> (deadjusted heads, the usual thing with DATs). When accessed with dd(1) or
> tar(1), the drive couldn't even read its own "handwriting" and tried
> several strategies for recovery. During these attempts the kernel would
> lose its temper, send a (useless) ABORT to the SCSI target and hang the
> related process indefinitely.
> 
> But then, MacOS wasn't able to cope with the situation, either...

You don't happen to have a decent MacOS tape backup program, do you? ;)
I'm glad to say that I've had more luck under NetBSD with my tape drive.

On another note, anyone know why SBC locks up on eg. mt rewind, while
NCRSCSI does not? Is it my kernel SBC options?

Thanks for the info guys!
--
Paul Ripke
BHP Information Technology
Open VMS, AXP & UNIX (AIX, DG/UX, SCO, IRIX, Digital, SunOS...) Sysadmin
 Computer Centre,  Five Islands Rd,  Port Kembla,  NSW 2505,  AUSTRALIA
  stixpjr@ozemail.com.au   weripp@itwol.bhp.com.au   pjr02@uow.edu.au
         Anyone wishing to lay claim to the opinions expressed
                   herein, do so at their own risk.