What does "clocksource tsc unstable" mean?

Solution 1:

I honestly see this message for the first time today and have no clue what it actually means.

That being said, I read the Wikipedia article on the Time Stamp Counter (which is what the tsc in the error message stands for). The article mentions a problem with the TSC in the second paragraph:

The time stamp counter has, until recently, been an excellent high-resolution, low-overhead way of getting CPU timing information. With the advent of multi-core/hyperthreaded CPUs, systems with multiple CPUs, and "hibernating" operating systems, the TSC cannot be relied on to provide accurate results — unless great care is taken to correct the possible flaws: rate of tick and whether all cores (processors) have identical values in their time-keeping registers. There is no promise that the timestamp counters of multiple CPUs on a single motherboard will be synchronized. In such cases, programmers can only get reliable results by locking their code to a single CPU. Even then, the CPU speed may change due to power-saving measures taken by the OS or BIOS, or the system may be hibernated and later resumed (resetting the time stamp counter). In those latter cases, to stay relevant, the counter must be recalibrated periodically (according to the time resolution your application requires).

In short, on modern systems, the TSC sucks for measuring time accurately. And that's what the message is telling you. On your system, the TSC is not a stable time source.

The delta noted, I would assume, is the reported time delta between two ticks of the TSC. Meaning, every time the TSC counts up 1, NNNNNNNNN nanoseconds will have passed. So, that's how you usually can keep very accurate time.

The linux kernel will have checked this frequency multiple times (to determine if the source is stable) and it got different results. Thus, the message.

So, do you need to be concerned?
I honestly don't know. To my understanding, this problem arises from processes being "moved" between cores (every core could have a different TSC frequency) or a core changing its core frequency (like with power saving).

Most likely, the message is only printed because the kernel detected this issue for itself and will now adjust accordingly.

And, from what I read in the kernel sources (arch/x86/kernel/tsc.c), I don't think I'm too far off with my assumptions.

I doubt the message means a critical condition. And I base that on the assumption that you would know by now if it was critical.