On Fri, 14 Dec 2007, Eduard-Gabriel Munteanu wrote: > LAPIC is seemingly disabled (C1E detection code does this), but > clockevents still tries to use it, instead of relying on HPET.
It relies on HPET. The LAPIC is just used as a mechanism which allows us to broadcast the tick to both cores. > I'll look into this, but please give me a heads up if you know more > about what's happening. Looks like fixing this is better than using > LAPIC for dynticks (and disabling C1E) on such systems. Yes, it's definitely worth fixing, but it's not trivial: For Highres/dyntick we need per CPU clock event devices to avoid serialization and broadcasting overhead in the normal operation mode. The LAPIC timer is per CPU, fast and the best thing we have, except for C1E enabled AMD systems. The perfect solution for those systems would be to use the HPET channels seperately as per CPU clock event devices. Venki tried this some time ago, but it's hard to resolve simply because none of the BIOSes gives us an idea to which interrupts we can route the HPET channel interrupts. The only choice we have is to use the legacy interrupts, which gives us the headache of emulating the RTC via the HPET and some other stupid legacy issues. We can not utilize the broadcast mechanism of the cpuidle code because we do not have an idea that we are going into C1E as it is done magically in the SMM code. To work around this is we would need to add the broadcast notification to the halt(), safe_halt(), pm_idle_halt() variants which float around in the kernel and make this conditional on the C1E detection. That's nasty, but it seems the only solution for now. Thanks, tglx -- 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/