Re: [PATCH] Dynamic tick, version 050127-1

From: Tony Lindgren
Date: Tue Feb 01 2005 - 18:08:33 EST


* Pavel Machek <pavel@xxxxxxx> [050201 13:50]:
> Hi!
>
> > > I used your config advices from second mail, still it does not work as
> > > expected: system gets "too sleepy". Like it takes a nap during boot
> > > after "dyn-tick: Maximum ticks to skip limited to 1339", and key is
> > > needed to make it continue boot. Then cursor stops blinking and
> > > machine is hung at random intervals during use, key is enough to awake
> > > it.
> >
> > Hmmm, that sounds like the local APIC does not wake up the PIT
> > interrupt properly after sleep. Hitting the keys causes the timer
> > interrupt to get called, and that explains why it keeps running. But
> > the timer ticks are not happening as they should for some reason.
> > This should not happen (tm)...
>
> :-). Any ideas how to debug it? Previous version of patch seemed to work better...

I don't think it's HPET timer, or CONFIG_SMP. It also looks like your
local APIC timer is working.

If you have a serial console, you can put one letter printks in the
code. Can you check if you ever get to smp_apic_timer_interrupt()?
That's where you should get to after the sleep, and that calls the
PIT timer interrupt to get it going again. I'm thinking that you'll
get to smp_apic_timer_interrupt(), but once therebut function
dyn_tick->interrupt(0, NULL, regs) never gets called.

It's OK to put printks to the timer code here, there's tons of
output only when the system is busy :)

Also, can you post your .config again? And also please post output
from:

dmesg | grep -i "time\|tick\|apic"

> > I've noticed that the only machine I have with ACPI C2/C3 support
> > does not do anything in the C2/C3 loops, it just spins around and
> > consumes more power than in C1 with hlt!
> >
> > That's because we currently don't have any code to enable the C2/C3
> > states in the southbridges on many Athlon boards. It's the same
> > problem on my Crusoe laptop ALi 1533 chipset.
>
> I do not think we should need any chipset-specific code. ACPI
> is expected to solve it... Can you ask on acpi-devel?

Yeah, I've been meaning to, I just subscribed to it yesterday.

Tony
-
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/