RE: Interrupts being reported twice?

Robert Watson wrote:

> I see the same problem in 4.x.  Drew and I exchanged some e-mails
> comiserating over the fact that this seems to be the case on a lot of
> machines.  Not that this is necessarily what you're seeing, 
> but it would
> be interesting to know whether in previous configurations you see
> different symptoms of a similar problem.

With the old configuration (a kernel from 3 or 4 days ago, ACPI disabled
(but APIC enabled since it's an SMP system), and two of the PCI cards
switched around), this is what I was getting:

(copied from the "Current crash on today's kernel" thread)

# vmstat -i
interrupt                          total       rate
irq1: atkbd0                           2          0
irq0: clk                        5142796        995
irq4: sio0                          1056          0
irq6: fdc0                            10          0
irq8: rtc                         658343        127
irq13: npx0                            1          0
irq14: ata0                       205255         39
irq15: ata1                       205046         39
irq16: em0 atapci1              11635073       2251
irq17: em1 ahc0++                6549430       1267
irq19: atapci4+                   442467         85
Total                           24839479       4807

As you can see, em0 (the source with the highest interrupt load) didn't sit
on its own ithread. Instead it shared it with the Promise SATA150 TX4
controller. em1/ahc0/atapci2+ shared irq17, and the interrupt count on that
ithread looks about right. 

Something in this configuration has crashed my machine 3 times in 6 days, so
I'm not looking to go back unless the new config also results in crashes.


Back to the current config (ACPI enabled):
What about running the kernel with DEVICE_POLLING enabled? I've seen posts
here saying it doesn't make any sense to do so in the SMP case, but I've
also seen people report that they are doing it (by modding the appropriate
file to allow the compile to finish). Does it really not make any sense
doing it in SMP, or is it a matter of insufficient testing/debugging of the
code, or are there other reasons not to do it?

My thinking here is that if the NIC doesn't generate any interrupts, the
ithread that reports the "ghost" interrupts (atapci1+) should no longer do
that.

Maybe the real question is: does the ithread that reports the "ghost"
interrupts actually service all the interrupts, or is 'vmstat -i' reporting
something that really doesn't consume any CPU time?

/Daniel Eriksson