Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24

[Karsten Wiese <annabellesgarden@yahoo.de>]

Am Dienstag, 12. Juli 2005 16:25 schrieb Daniel Walker:
> On Tue, 2005-07-12 at 16:02 +0200, Ingo Molnar wrote:
> > * Karsten Wiese <annabellesgarden@yahoo.de> 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 Ahlon64_UP@k8T800: 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/