Re: Clocksource tsc unstable (delta = -8589361717 ns) in currentgit
From: Markus Trippelsdorf
Date: Tue Oct 26 2010 - 09:58:23 EST
On Tue, Oct 26, 2010 at 03:18:43PM +0200, Borislav Petkov wrote:
> On Tue, Oct 26, 2010 at 07:20:52AM -0400, Markus Trippelsdorf wrote:
> > On my AMD system the following kernel messages are sometimes printed
> > after several hours of uptime:
> > Clocksource tsc unstable (delta = -8589361717 ns)
> > Switching to clocksource hpet
>
> This is strange, tsc is actually stable on your F10h revC.
Yes. constant_tsc is among the CPU flags.
> > This happened several times already:
> > # grep "Clocksource" kernel.*
> > kernel.log:Oct 24 18:31:17 arch kernel: Clocksource tsc unstable (delta = -8591703466 ns)
> > kernel.log:Oct 26 12:54:38 arch kernel: Clocksource tsc unstable (delta = -8589361717 ns)
> > kernel.log.1:Oct 22 21:43:51 arch kernel: Clocksource tsc unstable (delta = -25772316650 ns)
>
> Do you have any warnings/oopses before that, can we have the whole dmesg
> with the above messages?
No warning/oopses. The whole dmesg is attached.
>
> > The computer is nearly unusable afterwards (second long delays, that
> > seem to grow larger and larger) and only a prompt reboot can fix the
> > problem.
> > I'm running the latest git kernel. Version 2.6.36 does not show these
> > symptoms.
> >
> > Dmesg and kernel config are attached.
> >
> > --
> > Markus
>
> > Initializing cgroup subsys cpu
> > Linux version 2.6.36-05618-gb18cae4-dirty (markus@xxxxxxxxxxxxxxxxxxxx) (gcc version 4.5.1 (GCC) ) #41 SMP PREEMPT Tue Oct 26 06:51:47 CEST 2010
>
> ...-dirty means you have some changes ontop of b18cae4. What are those?
The SCHED_AUTOGROUP patches from Mike Galbraith.
> > Command line: root=/dev/sdb2 fbcon=rotate:3 quiet kexec_jump_back_entry=0x23d64482b7e72bb7
> > BIOS-provided physical RAM map:
>
> otherwise, I don't see anything strange in your dmesg. Unless tglx has a
> better idea, I'd ask you to bisect it. 5618 changesets shouldn't be that
> much but I don't know, if the issue appears every several hours it could
> still be tedious.
That would be a several week long process, as the issue appears ~ every
2 days here on this machine running 24/7.
--
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/