Re: Interrupts being reported twice?

On Monday 19 April 2004 11:46 am, Daniel Eriksson wrote:
> 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?

The problem is in hardware, and the CPU is actually receiving interrupts from 
the interrupt controller for both IRQs.  Each ithread is scheduled and all of 
your ISRs are running, though if they are for smarter devices they will 
return after doing an interrupt status register check.

-- 

John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/