Re: Undo aic7xxx changes (now rc7+aic20030603)

[Stephan von Krawczynski]

On Tue, 10 Jun 2003 09:51:34 -0400 (EDT)
Zwane Mwaikambo <[e-mail]> wrote:

> > Reading around the whole interrupt stuff I came across a very simple idea
> > which I am going to test right now. See you in some hours ;-)

I now tried rc7+aic20030603 SMP apic _but_ interrupts from aic only bound to
single cpu. I did this with help of irqbalance from Arjan.

/proc/interrupts:

           CPU0       CPU1       
  0:       5148     571297    IO-APIC-edge  timer
  1:       9733         97    IO-APIC-edge  keyboard
  2:          0          0          XT-PIC  cascade
 12:      43720       1271    IO-APIC-edge  PS/2 Mouse
 15:          4          4    IO-APIC-edge  ide1
 17:       1297    1336383   IO-APIC-level  3ware Storage Controller
 18:        344      16447   IO-APIC-level  eth0, eth1
 20:        570          3   IO-APIC-level  fcpcipnp
 21:      57292        340   IO-APIC-level  eth2
 22:     443161       2776   IO-APIC-level  aic7xxx
 23:         31    2005037   IO-APIC-level  aic7xxx
 26:          0          0   IO-APIC-level  EMU10K1
NMI:     593524     582633 
LOC:     576356     576330 
ERR:          0
MIS:          0

The controller used is the second aic7xxx. The 31 interrupts on CPU0 have
occured before the test. This setup fails during verify (data corruption).

I would say that the interrupt code of the aic in itself is therefore ok with
SMP. If it were a SMP race condition inside the interrupt routine this test
should have been ok (as only one CPU is used).

Regards,
Stephan