Re: Undo aic7xxx changes (now rc7+aic20030603)

[Stephan von Krawczynski <skraw@ithnet.com>]

On Mon, 9 Jun 2003 21:38:16 -0400 (EDT)
Zwane Mwaikambo <zwane@linuxpower.ca> wrote:

> On Mon, 9 Jun 2003, Stephan von Krawczynski wrote:
> 
> > During the whole testing with SMP I recognised that the tar-verify always
> > brought up "content differs" warnings. Which basically means that the
> > filesize is ok but the content is not. As there might be various causes for
> > this (bad tape, bad drive, bad cabling) I did not give very much about it.
> > But it turns out there are no more such warnings when using an UP kernel
> > (on the same box with the complete same hardware including tapes).
> > 
> > >From this experience I would conclude the following (for my personal test
> > case):
> 
> Can you also try this with 2.5?

Uh, do I trust Linus ? ;-) Well, probably I am going to take a look. The whole
story eats a lot of time as I have to deal with GBs of data for every single
test.

> > 1) aic-driver has problems with smp/up switching (meaning crashes when
> > trying an SMP build with nosmp). This is completely reproducable.
> 
> Can you also try an SMP kernel with noapic?

Can you clarify? Do you mean options "nosmp noapic" or just "noapic" on SMP
kernel?

> > 2) aic-driver (almost no matter what version) has problems with SMP setup
> > and tape drives. Obviously data integrity is not given. This is completely
> > reproducable in my test setup.
> 
> I have had problems with symmetric interrupt handling but can normally get 
> it working with noapic. And no it doesn't appear to be an interrupt 
> routing problem on my box (If it is someone please clearly state what the 
> exact problem is to me)

Hm, my question is: if it were exclusively an apic problem, why do other
controllers (in a filesystem environment) work flawlessly. Maybe the driver and
apic simply have differing opinions in certain race cases, but that does not
mean that apic is always to blame, does it?

Regards,
Stephan