Re: [PATCH] I/O APIC: Timer through 8259A revamp

[Maciej W. Rozycki]

On Mon, 19 May 2008, Andi Kleen wrote:

> >  With the ACPI tables, hardware is modern enough the timer interrupt 
> > should be directly available, but is usually wired in the way recommended 
> > by the MP spec.
> 
> I originally had that assumption too, but in practice that doesn't seem
> to be always the case unfortunately. Or sometimes the tests just fail
> for whatever reason and they drop into the fallback path.

 Well, the fallback path was meant to be used with hardware suffering from
limitations and not from broken configuration tables.  If the
configuration recorded in the tables is broken, then who knows what the
hardware looks like?  Anything may happen.  This should really be the case
for: "Fix your *** firmware!"  With Flash memories in wide use today,
there is really no excuse and the technology behind these tables does not
require a rocket scientist.

> >  That is the output of the master 8259A goes to INT0 of 
> > the I/O APIC (or is only connected to local APICs) and the timer is routed 
> > to INT2.  
> 
> There are already a couple of wiring differences in common chipsets.
> Mostly hurts on the fallback path especially when multiple sources are 
> enabled (then you might end up with duplicated interrupts, happened often
> on ATI systems)

 As soon as you hit the through-8259A mode chances are you will start
suffering from things like assumptions about the state of the hardware
made by whoever has written SMM code for this system, which may result in
reassertion of the interrupt that has already been handled (the mode of
operation of the 8254 does not help here).  Otherwise if the timer
interrupt genuinely arrives through multiple I/O APIC inputs, then we have
a piece of sloppy code somewhere -- we should never have more than one
input at a time with the same interrupt vector enabled; this is also a
grey area of operation of the APIC itself, at least with some
implementations.

> >  The use of the local APIC timer as a replacement was recommended back
> > then,
> 
> That was before CPU power saving was invented I guess @)

 Well, the i386SL was *the* power-saving Intel CPU when the i82489DX was
being worked on and certainly back then nobody sane would go through the
pain of putting additional CPUs into a system only to make them go to
sleep. ;-)  The SMM had already been committed in that CPU in case you
were asking...

> > but I think IRQ8 from the RTC was also a good solution, 
> 
> Trouble on Linux is that RTC doesn't support any of the traditional HZ 
> values. I considered writing a RTC driver back then, but didn't do
> it because of this. 
> 
> On the other hand with wider use of tickless kernels and hrtimers it might 
> be tolerable to use non standard HZ,

 I don't think the value of HZ should be a problem anymore now that we
have a separate user-visible HZ -- and it's been a while like that.  We
have a choice of three values of HZ already and for example the MIPS port
uses the closest powers of two to the usual values of 100, 250 and 1000
where necessary because of the very same reason and I haven't heard about
any problems resulting from that.

 Note some systems have the polarity reported incorrectly for the RTC 
interrupt -- that can be easily solved, but care has to be taken.

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