Re: Clocksource tsc unstable (delta = -8589361717 ns) in current git

Markus Trippelsdorf
2010-10-26T13:58:15Z

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@arch.trippelsdorf.de) (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