public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Milan Plzik <milan.plzik@gmail.com>
To: Robert Hancock <hancockr@shaw.ca>
Cc: Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org, tglx@linutronix.de
Subject: Re: Timer unstability on when using C2 and deeper sleep states (Dell Latitude XT)
Date: Thu, 14 Aug 2008 10:10:42 +0200	[thread overview]
Message-ID: <1218701442.4285.15.camel@localhost> (raw)
In-Reply-To: <48A3BED6.3070207@shaw.ca>

On St, 2008-08-13 at 23:12 -0600, Robert Hancock wrote:
> Milan Plzik wrote:
> > On St, 2008-08-13 at 22:17 +0200, Andi Kleen wrote:
> >> Milan Plzik <milan.plzik@gmail.com> writes:
> >>
> >>>   I apologize for replying on my own mail (and also for top-posting, but
> >>> this information is global update, not exactly fitting any of topics
> >>> mentioned below).
> >>>
> >>>   After playing for a longer while I found out that the system ends
> >>> sometimes in state where, in order to do anything useful, I need to
> >>> press keys on keyboard. 
> >> This usually means it is using the wrong timer in a deeper idle state.
> >> Some idle states cannot be woken up by e.g. the APIC timer and then
> >> you get that effect: you only make progress when you wake up the 
> >> CPU in some other way like pressing a key. Then on wake up the
> >> timers get processed.
> >>
> >> This is usually a bug in the kernel timer selection. It should be chosing
> >> a timer that always wakes up from the deepest idle state used.
> > 
> >   Last days I also considered this option; I tried all possible timers (hpet, tsc, acpi_pm), but their behavior is the same. 'jiffies' timer works correctly, but that one doesn't seem to put CPU to deeper sleeps, so we can't deduce any information from that. 
> > 
> >   I've seen some workaround in drivers/acpi/processor_idle.c, which seems to check the ARCH_APICTIMER_STOPS_ON_C3 macro, but it's enabled at compilation time, so the code is used by kernel... .
> 
> That changes the clock interpolation source, but it doesn't change the 
> timer interrupt source though, which is quite possibly what you're 
> losing. Have you tried nolapictimer kernel option (or nolapic, which is 
> the bigger hammer)?

  I tried both on 2.6.26 kernel; nolapic_timer resulted in a bit (from
my view) more sane results in powertop, but the freezes remained. With
nolapic system seemed to run fine, but it also disabled SMP support.
Maybe the issue is also SMP-related...

  Thank you,
	Milan

  


  reply	other threads:[~2008-08-14  8:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.BPxGhvxOK2Rcn4TTNlAMe2XzVYk@ifi.uio.no>
     [not found] ` <fa.s5pgfnYl3W8cOu+PDLbvAcv4X9c@ifi.uio.no>
     [not found]   ` <fa.2qnH5HZa4bnjN4HRRidEAUj5jxk@ifi.uio.no>
     [not found]     ` <fa.b1y/njcuV4QYZ2xTsVkHQ55Ni7Y@ifi.uio.no>
2008-08-14  5:12       ` Timer unstability on when using C2 and deeper sleep states (Dell Latitude XT) Robert Hancock
2008-08-14  8:10         ` Milan Plzik [this message]
2008-08-12 18:33 Milan Plzik
2008-08-13 10:58 ` Milan Plzik
2008-08-13 13:05   ` Pavel Machek
2008-08-13 14:33     ` Milan Plzik
2008-08-13 20:17   ` Andi Kleen
2008-08-13 21:04     ` Milan Plzik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1218701442.4285.15.camel@localhost \
    --to=milan.plzik@gmail.com \
    --cc=andi@firstfloor.org \
    --cc=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox