Am Dienstag, 12. Juli 2005 16:25 schrieb Daniel Walker:
> On Tue, 2005-07-12 at 16:02 +0200, Ingo Molnar wrote:
> > * Karsten Wiese <[EMAIL PROTECTED]> wrote:
> > 
> > > Hi Ingo
> > > 
> > > I've refined io_apic.c a little more:
> > 
> > great. I've applied these changes and have released the -28 patch. (note 
> > that the last chunk of your patch was malformed, have applied it by 
> > hand.)
> > 
> > i'm wondering what your thoughts are about IOAPIC_POSTFLUSH - i had to 
> > turn it on unconditionally again, to get rid of spurious interrupts and 
> > outright interrupt storms (and resulting lockups) on some systems.  
> > IOAPIC_POSTFLUSH is now causing much of the IO-APIC related IRQ handling 
> > overhead.
> 
> I observed a situation on a dual xeon where IOAPIC_POSTFLUSH , if on,
> would actually cause spurious interrupts. It was odd cause it's suppose
> to stop them .. If there was a lot of interrupt traffic on one IRQ , it
> would cause interrupt traffic on another IRQ. This would result in
> "nobody cared" messages , and the storming IRQ line would get shutdown.
> 
> This would only happen in PREEMPT_RT .
> 
i've only tested on 2005ish [EMAIL PROTECTED]: it doesn't need any of the quirks
  IOAPIC_POSTFLUSH, sis_bug, level-edge cleanup.
IOAPIC_POSTFLUSH caused no negative influence neither.
i've an io_apic_one.c here, that doesn't have any of the quirks and is stripped 
down
to handle just one ioapic. It runs just fine on PREEMPT_RT.
Could be used as a "Do i crash/suffer without the quirks?" test for 1 ioapic 
equipped machines.
Should i post it?

On vanilla level-interrupts behave "nervously" showing the "doubled rate" 
effect:
For level interrupts vanilla just sends an EOI to the apic. Nothing else should 
be necessary (io)apic wise.
Only here, when the edge-level triggered hardware-handler acknowledges its 
client
(== resets the interrupt line) the doubled level interrupt is triggered on the 
same pin.
Thus the same interrupt routine runs again as soon as EOI has been sent and 
IFlag is open again.
hardware-handler receives it, does nothing and returns with "uninterested" 
<<insert correct macro here<.
everything works correctly though. its just some cycles wasted.
Odd, no? I found that the correct interrupt handling can be achieve by obeying 
the PREEMPT_RT method:
        level-interrupt triggers
                ioapic pin is masked
                        harware-handler deasserts pin/line
                apic gets eoi
                ioapic pin is unmasked
this could be optimized by ioapic caching , but there must be some 
configuration tweak......
that i don't know of. there are no via docs for me. erm.. anybody sends me a 
link _offlist_ ?-)
Or even _knows that tweak_ ?
And again IOAPIC_POSTFLUSH has no influence here on the doubled interrupt (VIA 
K8T800 only ?)
bug.

    Karsten

        

        
                
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: 
http://mail.yahoo.de

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to