On Wed, 23 Dec 2009, Mark Hounschell wrote:
Hmm. Looks like hpet2 is still getting used instead of local APIC timer in .28 case.
I was expecting some low number in hpet2 and local timer on all CPU to be around the same value. Above shows CPU 0 is depending on hpet2 for some reason even with idle=halt. Can you send the output of below two in case of .28 /proc/timer_list
Attached.
Oh wow. That's crazy: Tick Device: mode: 1 Per CPU device: 0 Clock Event Device: hpet2 max_delta_ns: 2147483647 min_delta_ns: 5000 mult: 61510047 shift: 32 mode: 3 next_event: 123991000000 nsecs set_next_event: hpet_msi_next_event set_mode: hpet_msi_set_mode event_handler: hrtimer_interrupt Tick Device: mode: 1 Per CPU device: 1 Clock Event Device: lapic max_delta_ns: 670831998 min_delta_ns: 1199 mult: 53707624 shift: 32 mode: 3 next_event: 123991125000 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: hrtimer_interrupt ... It's not using the lapic for CPU0. Using the HPET as a per-cpu timer is some crazy sh*t, since it's pretty expensive to reprogram (compared to the local apic). And having different timers for different CPU's is just odd. The fact that the timer subsystem can do this and it all (mostly) works at all is nice and impressive, but doesn't make it any less crazy ;) That said, none of this seems to explain why DMA/fdformat doesn't work. Linus