This patch applies cleanly to 2.0.33.  Anyone attempting to use this driver
with kernels in the 2.1.x series should download both the tarball and the
patch file.  Generally speaking, you'll want to unpack the aic7xxx tarball
somewhere that won't actually put the files into the kernel sources, then
look at the patch file to see about any conflicts (for example, you will
probably have to hand merge the code in drivers/pci/pci.c and
include/linux/pci.h due to changes in the 2.1 kernel series).  All of the
aic7xxx files should simply be dropped into the 2.1.x kernel tree as is,
while the above mentioned two files, as well as Documentation/Configure.help
will have to be hand merged most likely.

People that are paying attention will notice a one line patch to 
linux/kernel/printk.c is also present.  This patch simply increases the
size of the printk ring buffer.  Since this is an experimental patch, it
can produce *lots* of output information, both at boot and during runtime,
depending on the value of aic7xxx_verbose as set during the bootup or
during module load time.  I increased the ring buffer size so more of
the messages from bootup will get saved in the syslogd/klogd output.
However, the output of dmesg will not reflect the increased ring buffer
size unless you want to recompile dmesg to know about the larger size.

OK, now, having said that, on to the changes in this driver release.

First, this is the first aic7xxx driver under linux to support the aic7895
chipset.  Special thanks from me to the gentlemen at Suse for providing
hardware upon which to test this driver (thanks especially go to
Hubert Mantel).

Second, with this version of the driver I've also attempted to start an
update on the *very* outdated README.aic7xxx file found in drivers/scsi.
People should take a look at this file as it now has all kinds of
information that it didn't used to have.

Third, some of the messages the driver used to print out weren't very clear
unless you already knew what the message meant.  For those messages
intended to give instruction to the end user (such as the warning about
Auto Termination being enabled), the printks have been cleaned up and the
wording changed so that it is more helpful (hopefully).

Fourth, this driver uses an entirely new sequencer.  With that new sequencer
came the end to some old, long standing problems.  For instance, with the
old driver and SCB_PAGING enabled, the aic777x class controllers and the
aic785x class controllers could only support a small number of total
commands.  This is no longer true.  Now, *every* controller we support
has a maximum of 255 commands active at any one point in time.  This was
a side effect of no longer using the QINFIFO and QOUTFIFO registers at all
in this driver (these registers were broken on the mentioned chipsets, and
don't even exist on the aic7895 chipset, so their time had come).

Fifth, there is one new boot time option so far, and a few missing options
that weren't actually being honored anyway.  The new option is called
reverse_scan.  By setting this variable to anything other than 0 during
boot or insmod time, the driver will reverse the order in which it is
registering PCI controllers in an attempt to keep that order identical to
that of the BIOS and other OSes.  However, in a mixed PCI/EISA environment,
regardless of this option, any EISA controllers that have their BIOS
enabled will get registered before PCI controllers.  This option isn't
perfect, but I hope it helps.  See the README.aic7xxx file for more
information.

Sixth, SCSI command completion handling now occurs outside of the aic7xxx
interrupt routine.  This helps to eliminate such problems as the mouse in X
being unresponsive during heavy disk activity.  It also helps general 
keyboard responsiveness.  It does not, in general, speed up your disks, or
make applications that are waiting on the disks for something any faster,
it's just the general responsiveness of non-SCSI related activity that
improves as a result.  Well, that and interrupts aren't disabled for
such long periods of time, so it's more system friendly in a general way.

Seventh, much of the probe code to find and register controllers has been
updated and modified.  The changes introduced should help people who have
had card detection problems in the past.  Feedback on this portion of
the code is requested by me :)

Eighth, a couple compile time options have disappeared.  Specifically,
SCB_PAGING is no longer an option, nor is TAGGED_QUEUEING.  This have
been supported, and stable, for eons with the exception of a very few
broken devices that say they can do tagged queueing but can't.  There
is now code in place to catch this condition and disabled tagged queueing
on those devices.  Secondly, the actual difference between the code with
PAGING enabled and with it disabled are nill, with the only difference
being how many commands we tell the mid level SCSI code we can queue.
Since both of these options can actually be emulated via the
AIC7XXX_TAGGED_QUEUEING_BY_DEVICE option, that's been left in place
while the other two have been taken out.  In the near future I want to
add another command line option to set the tagged queueing by device
parameters so that changing it doesn't require a recompile, but for
now, it does.

Ninth.....well, there's a lot more changes in there, but I won't go through
them all :)


So, what's left to be done?  Any known problems?

Hmmm...well, first off, I haven't yet figured out exactly where the 7895
chipset BIOS stores the CHANNEL_B_PRIMARY flag, so currently the driver
will always register channel A first.

Flaky drives can still cause resets, but as always, they should be non-fatal
and correct themselves.  There are still conditions that could lead to
a bus reset loop, for instance, I haven't yet implemented code to detect
and disable drives that are so badly gone that they wedge the SCSI bus
every time you send them a read or write command.

On occasion, I have seen one of those flaky Quantum Fireball Tempest drives
produce UNDERRUN or OVERRUN errors on this driver (which they did before
as well).  However, what's different from before is that the new sequencer
may retry the command *many* times before the drive stops the flakyness.
One example was 64 UNDERRUN errors, all identical, in a span of less than
a second to one device, and then nothing more.  The command completed
successfully and I never heard another peep from the device about it.


Well, that's all I can think of for now, so I guess I'll sit back and
wait for some people to send me some problem reports :)