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...

>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? ;)

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.)

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...

	hauke





--
"It's never straight up and down"     (DEVO)