Hi, anyone out there with an aic6360 and some spare inodes they want to
trash? :-) 

My motherboard has one of these chips soldered on to it, and I have written
a low level driver for this chip, that more or less fits in with the
current scsi system.  At the moment it is still evolving, and now and then
it behaves a bit oddly, but I have managed to run it with a couple of scsi
disks, one scsi-1 and one scsi-2.  Is there anybody out there that are
willing to put some of their inodes on the line and help me test the driver?

#Some info about the chip: 

The AIC-6360 is a semi-intelligent SCSI-chip.  It will handle arbitration
and (re)select more or less automatically for you, including timeouts.  It
also assists you somewhat in handling the various SCSI-bus phases and has a
couple of FIFOs to take up slack when transferring data, a 128 byte main
FIFO + a 8 byte FIFO to handle up to 8 byte REQ/ACK offsets when doing
synchronous SCSI.  It is supposed to be capable of running 10MB/s
synchronous SCSI (not that I think that it is a good idea with a
single-ended cable).  It doesn't have build in DMA-capability other than
the ability to pull a DREQ line, i.e. it relies on the host computers DMA
to perform the transfers if you don't want to do it by programmed I/O.

Summing up: The chip will help you run the SCSI-protocol, but the CPU will
still need to do a bunch of work, much more than with an advanced host
adapter.  This of course affects the performance.....

#Some info about the driver:
* Written specifically for the Adaptec IC 6360 SCSI controller,
  i.e. it probably won't work with any of the other Adaptec chips without
  modifications.  
* For the time being it uses programmed I/O (string ops) but
  I am studying the docs for my EISA ISP to see if I can use the DMA
  controller to do the data transfers.  (Doing programmed I/O, it is easier
  to operate in kernel virtual address space.  Also, as the iov/uio stuff
  seems to refer to physical addresses I have not touched that stuff yet.)  
* It supports disconnect/reselects (some bugs in there to chase down, I
  think) and may eventually support synchronous transfers (a question of
  getting the SCSI messages right and keeping sensible target info/state
  around).   
* As for performance, on a good night, with a full moon and a strong tailwind,
  going downhill and with a cheering crowd I have seen read transfer rates
  from /dev/rsd0a (QPD1800S) of approx 1800MB/s using dd.  Not stunningly
  fast, I know, but at least I can reach out and touch the bits.....
* Tested with ST-277N (you do not want to know), QPD1800S (1.8GB SCSI-2
  disk) and CP3200 (200MB SCSI-1 disk).
* Lacks industrialization, i.e. "works in an academic environment" :-).
  It works with my computer.  There may be quirks with other computers that
  I do not know about, but which I would like the driver to handle.

So, anyone in for a bit of inode massacring?  If so, e-mail me.  BTW: I
would appreciate if someone with targets != disks would come forward.  I
have no idea how/if the driver works against those.

Also, if anyone from the core-team should happen to have some minutes to
spare (not very likely I guess) I would be grateful if you could tip me off
of any changes (style/conventions/misunderstandings on my part/etc.) that
should be made to integrate the driver properly into the source tree (if
desired).  Again, e-mail me for a copy of the driver.

Finally, a warning:  The driver is probably prone to fail miserably now and
then and may barf violently upon your precious bits. So, if you are really
worried about your data you probably do not want a copy of this driver
(yet).

					-jarle
----
The "doesn't-fit" memory allocation strategy:
void *malloc(int len)
{
    return (rand ());
}

------------------------------------------------------------------------------