Subject: Re: Status of sbc scsi driver?
To: Paul Goyette <paul@pgoyette.bdt.com>
From: Scott Reynolds <scottr@edsi.org>
List: port-mac68k
Date: 05/01/1996 09:15:12
On Tue, 30 Apr 1996, Paul Goyette wrote:

> What's the current status on this driver?  Is it capable of handling tape 
> drives yet?  And is it faster or slower than the mac68k5380 driver?

The sbc driver is currently still a "Work In Progress."  It does handle
tape drives, though not as well as I would like.  In order to give you
some more useful information, I have to point out that there are two modes
the driver runs in:  polled mode, where the driver waits for each request
to complete before releasing the SCSI bus and returning control the the
kernel, and interrupt-driven mode, where the driver sets up requests and
relies on the SCSI controller to generate interrupts when it needs
attention.  Note that at the present time, *all* writes are done using the
polled mode.[*]

Polled access is somewhat slower (est. 10%) for disks, but significantly
slower for CD-ROM and tape devices.  It is important to note that this
mode can tie up the kernel for significant amounts of time, particularly
with slower SCSI devices, and miss _plenty_ of clock interrupts.

Interrupt-driven access is comparable to the stock driver, with no
significant speed difference that I can see.  I've tested it with disks,
my AppleCD 600e, and an Archive Viper 150e tape.  (This mode can be
enabled by adding a "flags 0x3" to the sbc0 line in the kernel config.) 
As noted above, I have not tested interrupt-driven writes at this point;
I'm going to do a backup before I start on that particular phase. :-)

A couple days ago, I discovered something that Allen had noticed, as well;
slower devices that intend to disconnect from the SCSI bus seem to confuse
the Mac SCSI logic into generating an "extra" interrupt.  I'm dealing
this case by dropping any SCSI IRQ interrupt from the system while the
driver is already handling an IRQ interrupt.

Finally:  the whole reason for the sbc driver is that I've had reliability
problems with the stock ncrscsi driver since it was introduced.  It could
be the "extra" IRQ interrupt that has been killing my filesystems all
along, but I'm not sure.  At the penalty of slower writes, for now, I've
gained a significantly more reliable machine.

--scott

PS - Make -SURE- you have at least v1.3 of sbc.c if you'd like to try
using it.

[*] Note that the driver's "polled mode" should not be confused with the
5380's PIO mode; the default operating mode of the driver uses polled
pseudo-DMA for most operations.  In this mode it operates much like the
1.0 SCSI driver did.