printk timestamps jumping back and forth in 2.6.25-rc.

["Alexey Zaytsev" <alexey.zaytsev@gmail.com>]

Hello.

Long story short, this is what I see in my dmesg:

http://romomatic.osuosl.org/share/xl0/dmesg-2.6.25-rc3
http://romomatic.osuosl.org/share/xl0/dmesg-2.6.25-rc3-clocksource-acpi_pm
http://romomatic.osuosl.org/share/xl0/dmesg-2.6.25-rc3-clocksource-hpet

Specifying clocksource=acpi_pm and hpet changes nothing.

Apart from the jumpy timestamps, I think the
scheduler is not working well, because the mouse
looses smoothness from time to time during
compilations. Not that noticeble, but definetely
worse than it was in 2.6.23. Probably might be related,
I don't know.

I tried to bisect the problem, but it first lead me to

commit 326e96b92306b7af24a3608ec01156cba17a3fc1
Author: Ingo Molnar <mingo@elte.hu>
Date:   Sun Jan 27 08:03:54 2008 +0100

    printk: revert ktime_get() timestamps

    revert 19ef9309273d26cb005cb23e6a370353dca91099.

    Kevin Winchester reported a lockup during X startup an bisected
    it to this commit.

Reverting this revert kind of worked:
http://romomatic.osuosl.org/share/xl0/dmesg-2.6.25-rc3-reverted
but clearly this was not the right thing. ;)

and after bisecting 2.6.24 - commit before
19ef9309273d26cb005cb23e6a370353dca91099
I got to

commit d713f519332e029d43eca8462629314eee1ded86
Author: Ingo Molnar <mingo@elte.hu>
Date:   Fri Jan 25 21:07:58 2008 +0100

    sched: fix CONFIG_PRINT_TIME's reliance on sched_clock()

    Stefano Brivio reported weird printk timestamp behavior during
    CPU frequency changes:

      http://bugzilla.kernel.org/show_bug.cgi?id=9475

    fix CONFIG_PRINT_TIME's reliance on sched_clock() and use cpu_clock()
    instead.

    Reported-and-bisected-by: Stefano Brivio <stefano.brivio@polimi.it>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>


which sound like "happy debugging, losers" to me. ;)

Anything else I can do?