ST01 driver for 386 unixes

[Mike Grenier]

>From article <1991Apr29.220501.26017 at smsc.sony.com>, by tin at smsc.sony.com (Le Tin):
> In article <1583 at integow.uucp> hot at integow.uucp (Roland van Hout) writes:
>>After you booted up and tried to access the scsi devices, the whole
>>system seems to hang!
> 
> The driver as released by Grenier has timing problems, as you had found
> out.  I've received reports from others of panics and lock ups. 

His problem appears to have nothing to do with *timing* problems
but instead with not having jumpered his board for the correct memory
address with what the driver expects. There is a constant in the
beginning of scsi.c that says where the card is mapped at and my 
distribution did not use the default settings as that conflicted
with the AMI bios in NEAT bios chipset on my motherboard. You can 
either change the define in the source or strap your card differently.

*** EVERYONE - please inform me if you are having timing or 
other problems *** . 

I have not had any reports to date.

> The
> current driver I am using is quite stable, it drives an ST02 with a CDC
> Wren III (150MB formatted) connected.  The Wren III happens to be my
> Usenet news disk, so it gets heavy usage.  I am running Interactive v2.0.2.

If it was so stable, I wouldn't have had to modify it! The basic ST-01 driver
had problems when more than one request was pending on multiple drives
at the same time. With one drive, as appears to be the case with your system,
the basic driver worked fine but it began to have trouble with multiple drives.
Consider :
     1) Start a request on drive 0
         (it may then disconnect)

     2) Start a request on drive 1
     
     3) drive 0 reconnects before step 2 has begun bus arbitration.
        Drive 1's bus arbitration will fail (as it should) but recovery
        doesn't appear correct.

In all fairness, my version of the driver that was psoted awhile back
didn't handle that case well either but it does now!

    -Mike Grenier
     mike at cimcor.mn.org