Doug's method for suppressing stray interrupt logging

[Ian Smith]

On Mon, 24 Jul 2006, Douglas W. Goodall wrote:

 > Hello Yousef and All,
 > 
 > In /usr/src/sys/i386/i386/intr_machdep.c:
 > 
 >     197         /*
 >     198          * For stray interrupts, mask and EOI the source, bump the
 > 
 >     199          * stray count, and log the condition.
 >     200          */    
 >     201         if (ie == NULL || TAILQ_EMPTY(&ie->ie_handlers)) {
 >     202                 isrc->is_pic->pic_disable_source(isrc, PIC_EOI);
 >     203 
 >     204 /*              (*isrc->is_straycount)++;                
 >     205                 if (*isrc->is_straycount < MAX_STRAY_LOG)     
 >     206                         log(LOG_ERR, "stray irq%d\n", vector);
 > 
 >     207                 else if (*isrc->is_straycount == MAX_STRAY_LOG)
 >     208                         log(LOG_CRIT,
 >     209                             "too many stray irq %d's: not logging
 > anymore\n",
 >     210                             vector);
 >     211 */ 
 >     212                        
 >     213                 return;
 > 
 > See line 204 where /* starts the suspension
 > See line 211 where */ ends the suspension
 > 
 > Ian,
 >  Your question was good. Since the IBM AT there have been two programmable
 > interrupt controllers in the architecture.
 >  The second one is slaved off the first one attached to the IR7 line of the
 > primary pic.

Hi Doug,

Hmm, perhaps I'm misremembering, but I was pretty sure the AT 2nd PIC
was connected to IRQ _2_ on the first, thus elevating the priority of
irqs 8-15 above those of irq 3-7, generally (then at least) used for
slower devices like serial comms and lpt?  Hence IRQ2/IRQ9 confusion? 

 >  The interrupt routine does the necessay things to remove a valid interrupt
 > cause and sends the End of Interrupt (EOI)command to the PIC.  

Yep.  And a stray interrupt can only occur when that interrupt isn't
masked off, ie is thought to be validly enabled for interrupt service.

 >  In the case of the "default ir7", there is no valid cause and that is why
 > it is called a stray interrupt.
 >  The interrupt code in 6.1 looks good but IMHO the code shouldn't bother to
 > log the strays.

I assume your above patch stop logging of ALL stray irqs?  I've seen,
for instance, flakey HD controllers report stray irq 15s, which is not a
message I'd want to miss out on seeing.  I've also see stray irq 3 & 4s
on some serial modem setups, that are usefully indicative of problems. 

 >  The code is handling them properly and my only contention is that the
 > messenger should be ignored.

Even where the laptop concerned is said to have a DB25 parallel printer
port that for some reason is not being detected by ACPI initialisation?

If Yousef needs his parallel port to work, he needs irq7 to work.  What
does seem odd is that irq7 is enabled in the first place, if not used?

 >  One coud say, "Gee my Sharp PC-MM20 has a noisy bus and gets more default
 > ir7's than some other box",
 > but in the pig picture a few extra trips into the interrupt code is not
 > enough cycles to sneeze at.

I'm not sure what you mean by 'default' irq 7s?  It's only the 'default'
for the parallel printer / ppbus port, as far as I know.

 > BTW: The reason I didn't just change the value of MAX_STRAY_LOG was a
 > nagging concern that if too many
 > Stray interrupts occurred (like 32768) there might be a signed/unsigned
 > comparison problem in the code
 > that might cause the logging suspension to fail unexpectedly.

Perhaps it might be better to reduce the value of MAX_STRAY_LOG so it
gives up logging after just two or three instances - if you want to see
them as spurious - than to bypass stray IRQ logging altogether, where it
could be most helpful where there is a genuine problem - as can happen?

Cheers, Ian

 > Is is a great honor for me to share some hard earned knowledge with the
 > community. :-)
 >
 > Respectfully,
 > 
 > Douglas W. Goodall
 > FreeBSD Enthusiast