On Wed, 2007-09-12 at 02:16 -0700, Andrew Morton wrote:
> On Tue, 11 Sep 2007 23:49:47 +0200 Thomas Gleixner <[email protected]> wrote:
>
> > On Tue, 2007-09-11 at 21:52 +0200, Thomas Gleixner wrote:
> > > > C1: type[C1] promotion[C2] demotion[--] latency[001] usage[00000010] duration[00000000000000000000]
> > > > *C2: type[C2] promotion[--] demotion[C1] latency[001] usage[00008316] duration[00000000000170717293]
> > >
> > > Ok, here we are. The bad one uses C2 which stops the local apic on the
> > > VAIO. I suspect we end up in the suspend/resume with going into C2
> > > without the broadcast active.
> > >
> > > Can you try to get the output of SysRq-Q during the "it needs help from
> > > keyboard" period ?
> >
> > Summary of the oddities we are seing:
> >
> > 1.) disabling local apic timer makes the problem go away
> > 2.) disabling nohz and highres makes the problem go away
> > 3.) adding the cpuidle patches from the acpi tree makes the problem go
> > away
>
> Only the fist cpuidle patch, actually. I'd have though this was a big hint?
Yes, it prevents the cpu to enter C2, which keeps the local APIC alive.
> > The obvious conclusion is, that in all other cases we run into a state,
> > where the local apic timer is not working.
> >
> > 1) we do not use it
> > 2) it is used in periodic mode
> > 3) the cpu does not enter C2 (which turns the lapic timer off on the
> > VAIO)
> >
> > While 1) and 3) are understandable, the reason why 2) is working is a
> > mystery because the periodic mode is affected by the C state as well.
> >
> > Andrew, can you please provide the output of /proc/timer_list when you
> > boot the kernel with "nohz=off highres=off", but honestly I do not
> > expect a lot of enlightenment from it.
> Tick Device: mode: 0
> Clock Event Device: pit
> max_delta_ns: 27461866
> min_delta_ns: 12571
> mult: 5124677
> shift: 32
> mode: 2
> next_event: 9223372036854775807 nsecs
> set_next_event: pit_next_event
> set_mode: init_pit_timer
> event_handler: tick_handle_periodic_broadcast
> tick_broadcast_mask: 00000001
> tick_broadcast_oneshot_mask: 00000000
Ok, I got my brain together and read through the code. The periodic mode
switches to broadcast right away when the acpi code discovers that there
is a lapic stops C-State available.
Does the test hack below fix the problem for nohz/highres enabled
kernels ?
tglx
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -382,6 +382,8 @@ static int tick_broadcast_set_event(ktime_t expires, int force)
int tick_resume_broadcast_oneshot(struct clock_event_device *bc)
{
+ cpu_set(smp_processor_id(), tick_broadcast_oneshot_mask);
+
clockevents_set_mode(bc, CLOCK_EVT_MODE_ONESHOT);
if(!cpus_empty(tick_broadcast_oneshot_mask))
-
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]
