Messages in this thread | | | Date | Mon, 19 May 2008 23:08:12 +0100 (BST) | From | "Maciej W. Rozycki" <> | Subject | Re: [PATCH] I/O APIC: Timer through 8259A revamp |
| |
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
| |