Re: Undo aic7xxx changes

[Justin T. Gibbs]

> Hi,
> 
> I've undone aic7xxx changes which were locking up some machines on
> initialization.

Hmm.  It would have been nice to have the oportunity to fix this correctly.
As it stands now, I have really no idea what people were testing or not
since by taking Alan's patch you have lost the complete change history
and the ability to step people through the changes.  I have preserved
this history in the bk send output that is available on my site if at
some point that is useful to you.

> The new driver is now named drivers/scsi/aic79xx and is under
> CONFIG_AIC79XX.

So we now have an extra copy of the assembler, the Config files, and
the aiclib files.  This is not a solution.  If you wanted to selectively
update the aic79xx driver, all you had to do was ask me for the requisite
change sets.  This is what a mainatiner is for.

> Justin, unfortunately I can't even THINK about updating aic7xxx to your
> new driver at the current release stage. I will do so in the 2.4.22.

Does this mean that you will actually take BK changes form me instead of
from just about anyone else that sends you aic7xxx driver updates?  I had
pretty much given up on this.

> The update also contains a PCI posting flush fix from Arjan.

Which is completely unnecessary and in fact will cause hangs and crashes
on many Dell servers.  The "fix" for the VIA systems that violate the
PCI spec is to either:

1) Update the driver correctly so that it's detection logic will
   automatically disable memory mapped I/O for these broken systems.

or 

2) Just disable the BIOS options that configure the system to violate
   the PCI prefetching rules.

Slowing down all systems, even the ones that are *not broken* by doing
extra, random, PCI read cycles is not a fix.

If you want some verification of the Dell issue (which I'm sure will
cause problems on other "fast" systems too), just ask Matt Domsh.

Again, if you have concerns about the aic7xxx or aic79xx drivers, my
mail box is always open.  Waiting to contact me until the last minute
where I can only sit on the sidelines and watch another train wreck is
not the best way to ensure that the drivers function correctly in 2.4.X.

What this basically boils down to is trust.  If you don't trust me,
tell me how I can build that trust.  Without it, I can only continue
to tell most people that contact me with bug reports, "It's already
fixed in the official driver.  You can pull the latest from ..."

--
Justin