[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1235335592.8805.214.camel@pasglop>
Date: Mon, 23 Feb 2009 07:46:32 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Paul Collins <paul@...ly.ondioline.org>,
"Rafael J. Wysocki" <rjw@...k.pl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Kernel Testers List <kernel-testers@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>
Subject: Re: [Bug #12667] Badness at kernel/time/timekeeping.c:98 in pmud
(timekeeping_suspended)
On Sun, 2009-02-22 at 20:31 +0100, Thomas Gleixner wrote:
> We had problems in the past where we just returned frozen time and the
> calling code got surprised when the time jumped 5 hours ahead just a
> few microseconds later.
>
> What I find more fishy is the fact that the lid switch needs to be a
> sysdev. It's a simple input event, which causes the user space code to
> trigger the suspend sequence when the lid is shut.
>
Well, the PMU is a sysdev for lots of good reasons.. then it -also-
happens to provide us with the lid switch event.
I'm a bit surprised by the explanation about the code that is surprised
to see the time jump. IE. Code -will- see the time jump anyway. IE. I
don't see how making gtod blow instead of returning a frozen time will
make any difference whatsoever for code who get the time some time
before suspend and then some time after resume and see a 5 hours gap...
Cheers,
Ben.
--
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/
Powered by blists - more mailing lists