linux-kernel - Re: Timer unstability on when using C2 and deeper sleep states (Dell Latitude XT)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <48A3BED6.3070207@shaw.ca>
Date:	Wed, 13 Aug 2008 23:12:54 -0600
From:	Robert Hancock <hancockr@...w.ca>
To:	Milan Plzik <milan.plzik@...il.com>
CC:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	tglx@...utronix.de
Subject: Re: Timer unstability on when using C2 and deeper sleep states (Dell
 Latitude XT)

Milan Plzik wrote:
> On St, 2008-08-13 at 22:17 +0200, Andi Kleen wrote:
>> Milan Plzik <milan.plzik@...il.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)?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/