Re: [patch] clockevents: drivers for i386, fix #2

[Thomas Gleixner]

On Wed, 2006-10-04 at 09:02 -0700, Andrew Morton wrote:
> On Wed, 04 Oct 2006 13:19:35 +0200
> Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/