Subject: Re: Crash reading from /dev/rst0
To: Paul Ripke <weripp@itwol.bhp.com.au>
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
List: port-mac68k
Date: 12/16/1997 21:47:17
At 0:57 Uhr +0100 12.12.1997, Paul Ripke wrote:
>hauke wrote:

>> >On another note, anyone know why SBC locks up on eg. mt rewind, while
>> >NCRSCSI does not? Is it my kernel SBC options?
>>
>> A question of timeouts? Though I don't know who is responsible for this:
>> The upper MI SCSI layer or the low-level driver.
>
>Sorry, should have been clearer - when using SBC, an 'mt rewind' will
>block most interupts until the operation completes - well, clock
>interupts anyway. Until the rewind completes, the machine appears
>"hung" - completely unresponsive.
>
>Using NCRSCSI, the rewind seems to be "queued" allowing the rest of
>the OS to continue normal operation. I can background the 'mt' and
>continue work.


Quoting from /sys/dev/ic/ncr5380.doc:

>This driver will permit reselection on non-polled commands if
>sc->sc_flags & NCR5380_PERMIT_RESELECT is 1.  This permits enabling of
>reselection on a per-device basis.
>
>Disconnect/reselect is never permitted for polled commands.

AFAIK, the sbc driver operates in polled mode unless you specify interrupt
driven operation by an option (which then makes it similar to the
interrupt-driven ncrscsi with similar problems).

	hauke


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