On Wed, 2006-10-04 at 09:02 -0700, Andrew Morton wrote:
> On Wed, 04 Oct 2006 13:19:35 +0200
> Thomas Gleixner <[email protected]> wrote:
>
> > On Wed, 2006-10-04 at 12:53 +0200, Ingo Molnar wrote:
> > > there's one material difference we just found: in the !hres case we'll
> > > do the timer IRQ handling mostly from the lapic vector - while in
> > > mainline we do it from the irq0 vector. So, how does your
> > > /proc/interrupts look like? How frequently does LOC increase, and how
> > > frequently does IRQ 0 increase?
>
> sony:/home/akpm> cat /proc/interrupts ; sleep 1 ; cat /proc/interrupts
> CPU0
> 0: 39256 IO-APIC-edge timer
> LOC: 3131
> 0: 39519 IO-APIC-edge timer
> LOC: 3134
delta IRQ == 263
delta LOC == 3
That explains the problem. The lapic frequency seems to be way off. I
have no good idea offhand how to detect such lapic brokeness.
> > static struct clock_event_device lapic_clockevent = {
> > .name = "lapic",
> > .capabilities = CLOCK_CAP_NEXTEVT | CLOCK_CAP_PROFILE
> > +#ifdef CONFIG_SMP
> > | CLOCK_CAP_UPDATE,
> > +#endif
> > .shift = 32,
> > .set_mode = lapic_timer_setup,
> > .set_next_event = lapic_next_event,
>
> that (after a tweak to make it compile) fixes it. What's it do?
It brings update_process_times() back into IRQ0. On systems with a
working lapic, it would not matter. SMP moves update_process_times() to
lapic too. That's why I asked whether a SMP=y kernel has the same
problems on this box.
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
