FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu User

 
 
LinkBack Thread Tools
 
Old 02-27-2009, 04:57 PM
Ray Parrish
 
Default Kernel clock issue "Clocksource tsc unstable"

Rashkae wrote:
>> One message I did grab says:
>>
>> 06:05:11 dio kernel: [1617517.563814] Clocksource tsc unstable (delta = 4686705598 ns)
>> 06:05:11 dio kernel: [1617517.573798] Time: acpi_pm clocksource has been installed.
>>
>> That was during a time server sync. In exactly 6 hours (at 12:05) that
>> same day, the clock stopped updating, logging stopped, ssh was fubar,
>> and I had to physically go to the datacenter and hit the reset button
>> to fix it.
>>
>> Sorry I can't really give you a canonical answer. tsc is an infamously
>> poor time keeper, but the kernel devs seem to prefer it over hpet
>> (Intel's High Precision Event Timer) because of performance. (tsc is
>> right in the cpu, wheras hpet needs to access a chip on the mobo).
>>
>> On my hard system where hpet is available, hardy defaults to that.
>> However, some systems do not have hpet, and kernel defaults to tsc. In
>> your case, tsc is deemed unstable and switches to acpi. Why this would
>> cause your clock to stop updating however, is a mystery, unless the acpi
>> hardware on your system is broken.
>>
>> The first step to resoling this, however, will be to determine what
>> clocksources you have available, and then choose one on boot (as a
>> kernel boot parameter.)
>>
>> sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>>
>> and:
>>
>> sudo cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>>
>> You can specify one of the available clocksources by editing your grub
>> menu.lst file and appending a clocksource= option to the kernel you
>> boot. For example, you can try clocksource=acpi_pm and test if acpi
>> works if you boot with it rather than switch to it. If acpi_pm doesn't
>> work reliably on your systems, I would then try hpet or pit if those are
>> available.
>>
>>
>>
Hello,

Sorry to butt in here, but I also receive the error messages about
clocksource tsc being unstable. I ran the command for available
clocksources and got the following output. "acpi_pm pit jiffies tsc" My
system switches to acpi_pm after the error message, but I would like to
read about the other available clocksource files before making a
decision on which to try to use from the menu.lst file.

The problem is that I cannot find any documentation on them on my
system. I used grep to search both the /usr/share/man and /usr/share/doc
folders for "clocksource" and came up empty. The same search on just
"clock" only comes up with desktop clocks and the hwclock man pages.

Do you know where I can read about the alternative clocksource files?

Thanks, Ray Parrish

--
Human reviewed index of links about the computer
http://www.rayslinks.com
Poetry from the mind of a Schizophrenic
http://www.writingsoftheschizophrenic.com/


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-27-2009, 05:11 PM
Hal Burgiss
 
Default Kernel clock issue "Clocksource tsc unstable"

On Fri, Feb 27, 2009 at 11:50:11AM -0500, Rashkae wrote:
> > I have probably at least 6 systems on 8.04LTS, but only have this
> > issue only on two of them, and these are radically different hardware.
> > At first I suspected a hardware issue when I only had this issue with
> > one machine. Now I have it with 2 so I can't imagine its hardware. To
> > make it worse, its very sporadic. On the one system, it happens
> > approximately once a month. The other system is new, has been running
> > about 2 months, and this was the first occurence.
> >
> > One message I did grab says:
> >
> > 06:05:11 dio kernel: [1617517.563814] Clocksource tsc unstable (delta = 4686705598 ns)
> > 06:05:11 dio kernel: [1617517.573798] Time: acpi_pm clocksource has been installed.
> >
> > That was during a time server sync. In exactly 6 hours (at 12:05) that
> > same day, the clock stopped updating, logging stopped, ssh was fubar,
> > and I had to physically go to the datacenter and hit the reset button
> > to fix it.

[...]

> Sorry I can't really give you a canonical answer. tsc is an infamously
> poor time keeper, but the kernel devs seem to prefer it over hpet
> (Intel's High Precision Event Timer) because of performance. (tsc is
> right in the cpu, wheras hpet needs to access a chip on the mobo).
>
> On my hard system where hpet is available, hardy defaults to that.
> However, some systems do not have hpet, and kernel defaults to tsc. In
> your case, tsc is deemed unstable and switches to acpi. Why this would
> cause your clock to stop updating however, is a mystery, unless the acpi
> hardware on your system is broken.

Hardware was my first strong suspicions. But when it happened on a
second system, then I don't know. This would be on 2 very radically
different systems (ie hardware).

> The first step to resoling this, however, will be to determine what
> clocksources you have available, and then choose one on boot (as a
> kernel boot parameter.)
>
> sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>
> and:
>
> sudo cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>

On the older system I get:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc acpi_pm jiffies

and its using tsc ATM. On the other, newer system:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource
acpi_pm jiffies tsc

and its *now* using acpi_pm, but I don't know what it was before
resetting it today. Its possible, that there had been a kernel update
somewhere and it did not kick in until the reboot and the clocksource
might be different. I had no log data at all on that system since
yesterday at 6:05, so I am in the dark on that one.


> You can specify one of the available clocksources by editing your grub
> menu.lst file and appending a clocksource= option to the kernel you
> boot. For example, you can try clocksource=acpi_pm and test if acpi
> works if you boot with it rather than switch to it. If acpi_pm doesn't
> work reliably on your systems, I would then try hpet or pit if those are
> available.

Thanks for the info! Very helpful.

--
Hal


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-27-2009, 07:18 PM
Rashkae
 
Default Kernel clock issue "Clocksource tsc unstable"

Hal Burgiss wrote:

>
> On the older system I get:
>
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> tsc acpi_pm jiffies
>
> and its using tsc ATM. On the other, newer system:
>
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> acpi_pm jiffies tsc
>
> and its *now* using acpi_pm, but I don't know what it was before
> resetting it today. Its possible, that there had been a kernel update
> somewhere and it did not kick in until the reboot and the clocksource
> might be different. I had no log data at all on that system since
> yesterday at 6:05, so I am in the dark on that one.
>
>
>> You can specify one of the available clocksources by editing your grub
>> menu.lst file and appending a clocksource= option to the kernel you
>> boot. For example, you can try clocksource=acpi_pm and test if acpi
>> works if you boot with it rather than switch to it. If acpi_pm doesn't
>> work reliably on your systems, I would then try hpet or pit if those are
>> available.
>
> Thanks for the info! Very helpful.
>


wow,, your hardware is a bit limited, with no hpet timer and no pic
timer.. (pic was the old standard timer). Jiffies, as I understand,
should be avoided like the plague and is only included for special
cases. (Jiffies is basically the software counting time based on cpu
clock frequency or some such.)

I would try adding clocksource=acpi_pm to the boot of both your systems
and see if that solves the problem.

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-27-2009, 07:39 PM
Rashkae
 
Default Kernel clock issue "Clocksource tsc unstable"

Ray Parrish wrote:

> Hello,
>
> Sorry to butt in here, but I also receive the error messages about
> clocksource tsc being unstable. I ran the command for available
> clocksources and got the following output. "acpi_pm pit jiffies tsc" My
> system switches to acpi_pm after the error message, but I would like to
> read about the other available clocksource files before making a
> decision on which to try to use from the menu.lst file.

Sorry, this is really deep magic stuff where mortals were really never
meant to thread. You practically have to dig through the kernel source
to find any scraps of useful information. I just got a crash course
about 6 months ago when I was trying to solve a clock drift issue. I'll
try to provide the cliff notes, but keep in mind, this is just my
understanding of things and I might be wrong about a fact or 2.

acpi_pm is the one I know least about, other than it works on my
computer, seems to be the standard default on recent hardware and it's
accurate.


pit - Programmable interrupt Timer, is the classic standard timer chip
that was at one time required on all 386 (and maybe all XT) class
hardware. In essence, the kernel can program it to tic at a given
interval, and software counts the tics (from CPU interrupts) to keep
track of time.

hpet - An intel and Microsoft joint standard, stands for high precision
event timer, was supposed to be a replacement for pit. According to
some kernel development noise I hear, it does become a bottleneck in
modern multi-threaded systems if multiple processes try to access the
timer.

jiffies - This is 'hardwareless' timer. The software keeps track of
time on it's own based on cpu clock cycles. Probably not good for
system performance, and I doubt it's accurate. My understanding is that
jiffies was never actually meant to be used.


tsc - I forget what the letters stand for.. tsc is part of your actual
CPU. I don't know what tsc was really meant for when designed, but it's
a poor choice for timer when time accuracy is important, because, well,
it's simply not accurate. When my system was using tsc, I would notice
time drift of almost 1 minute every hour. This seems to be considered
'ok' by people because you can just configure your computer to adjust
clock daily with ntp. Asside from the problem that tsc time will drift
depending on your system load, if you have a multi-core system, tsc will
drift from itself on different cores. Some multi-core cpu's will
synchronize tsc (I think the Intel Core 2 series, for example, but don't
quote me),, whereas other CPU's will lead to tsc being unstable and the
system switching to something else. (although, this should all happen
automagically, a system throwing a hairball over it should be considered
a bug.)




--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-27-2009, 09:21 PM
Hal Burgiss
 
Default Kernel clock issue "Clocksource tsc unstable"

On Fri, Feb 27, 2009 at 03:18:29PM -0500, Rashkae wrote:
>
> wow,, your hardware is a bit limited, with no hpet timer and no pic

The older one is dual P3's in an IBM server box. It ran fine for years
on CentOS and probably Gentoo before that, so this is all curious.
Either the hardware has gotten funky or something in the ubuntu server
kernel is funky. The newer one is a brand new AMD Opteron.

> timer.. (pic was the old standard timer). Jiffies, as I understand,
> should be avoided like the plague and is only included for special
> cases. (Jiffies is basically the software counting time based on cpu
> clock frequency or some such.)
>
> I would try adding clocksource=acpi_pm to the boot of both your systems
> and see if that solves the problem.

Thanks. I'll give that a shot.

--
Hal


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-27-2009, 09:57 PM
Rashkae
 
Default Kernel clock issue "Clocksource tsc unstable"

Hal Burgiss wrote:
> On Fri, Feb 27, 2009 at 03:18:29PM -0500, Rashkae wrote:
>> wow,, your hardware is a bit limited, with no hpet timer and no pic
>
> The older one is dual P3's in an IBM server box. It ran fine for years
> on CentOS and probably Gentoo before that, so this is all curious.
> Either the hardware has gotten funky or something in the ubuntu server
> kernel is funky. The newer one is a brand new AMD Opteron.
>

Oh, I'm more than willing to suspect a kernel bug or two




--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-27-2009, 10:12 PM
NoOp
 
Default Kernel clock issue "Clocksource tsc unstable"

On 02/27/2009 02:21 PM, Hal Burgiss wrote:
> On Fri, Feb 27, 2009 at 03:18:29PM -0500, Rashkae wrote:
>>
>> wow,, your hardware is a bit limited, with no hpet timer and no pic
>
> The older one is dual P3's in an IBM server box. It ran fine for years
> on CentOS and probably Gentoo before that, so this is all curious.
> Either the hardware has gotten funky or something in the ubuntu server
> kernel is funky. The newer one is a brand new AMD Opteron.

Don't feel bad... have an old Thinkpad A21M that doesn't have hpet either.

>
>> timer.. (pic was the old standard timer). Jiffies, as I understand,
>> should be avoided like the plague and is only included for special
>> cases. (Jiffies is basically the software counting time based on cpu
>> clock frequency or some such.)
>>
>> I would try adding clocksource=acpi_pm to the boot of both your systems
>> and see if that solves the problem.
>
> Thanks. I'll give that a shot.
>

I wonder if your issue is related to this:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/221351
[TSC Clocksource can cause hangs and time jumps]

You might also want to have a look at:
https://launchpad.net/ubuntu/hardy/+source/linux/2.6.24-24.50
Note the TSC/clock issues.

Changelog

linux (2.6.24-24.50) hardy-proposed; urgency=low

[Alok Kataria]

* x86: add X86_FEATURE_HYPERVISOR feature bit
- LP: #319945
* x86: add a synthetic TSC_RELIABLE feature bit
- LP: #319945
* x86: vmware: look for DMI string in the product serial key
- LP: #319945
* x86: Hypervisor detection and get tsc_freq from hypervisor
- LP: #319945
* x86: Use the synthetic TSC_RELIABLE bit to workaround virtualization
anomalies.
- LP: #319945
* x86: Skip verification by the watchdog for TSC clocksource.
- LP: #319945
* x86: Mark TSC synchronized on VMware.
- LP: #319945

You can click on the bugs in the changelog to have a look. Also:
https://launchpad.net/+search?field.text=TSC+Clocksource
[messy, but sometimes turns up a place to start when in doubt]



--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-27-2009, 10:53 PM
Hal Burgiss
 
Default Kernel clock issue "Clocksource tsc unstable"

On Fri, Feb 27, 2009 at 03:12:20PM -0800, NoOp wrote:
>
> I wonder if your issue is related to this:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/221351
> [TSC Clocksource can cause hangs and time jumps]
>
> You might also want to have a look at:
> https://launchpad.net/ubuntu/hardy/+source/linux/2.6.24-24.50
> Note the TSC/clock issues.
>

Could well be. Its a strange little critter. But I have not seen
a prompt return yet when I've been dealing with this head on. On the
first occasion, it hung one night. I retried the next morning, and
finally had to hike to the datacenter for a reset. It seems like a
real show stopper to me.

Thanks.

--
Hal


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-28-2009, 12:23 AM
Ray Parrish
 
Default Kernel clock issue "Clocksource tsc unstable"

Rashkae wrote:
> Ray Parrish wrote:
>
>
>> Hello,
>>
>> Sorry to butt in here, but I also receive the error messages about
>> clocksource tsc being unstable. I ran the command for available
>> clocksources and got the following output. "acpi_pm pit jiffies tsc" My
>> system switches to acpi_pm after the error message, but I would like to
>> read about the other available clocksource files before making a
>> decision on which to try to use from the menu.lst file.
>>
>
> Sorry, this is really deep magic stuff where mortals were really never
> meant to thread. You practically have to dig through the kernel source
> to find any scraps of useful information. I just got a crash course
> about 6 months ago when I was trying to solve a clock drift issue. I'll
> try to provide the cliff notes, but keep in mind, this is just my
> understanding of things and I might be wrong about a fact or 2.
>
> acpi_pm is the one I know least about, other than it works on my
> computer, seems to be the standard default on recent hardware and it's
> accurate.
>
>
> pit - Programmable interrupt Timer, is the classic standard timer chip
> that was at one time required on all 386 (and maybe all XT) class
> hardware. In essence, the kernel can program it to tic at a given
> interval, and software counts the tics (from CPU interrupts) to keep
> track of time.
>
> hpet - An intel and Microsoft joint standard, stands for high precision
> event timer, was supposed to be a replacement for pit. According to
> some kernel development noise I hear, it does become a bottleneck in
> modern multi-threaded systems if multiple processes try to access the
> timer.
>
> jiffies - This is 'hardwareless' timer. The software keeps track of
> time on it's own based on cpu clock cycles. Probably not good for
> system performance, and I doubt it's accurate. My understanding is that
> jiffies was never actually meant to be used.
>
>
> tsc - I forget what the letters stand for.. tsc is part of your actual
> CPU. I don't know what tsc was really meant for when designed, but it's
> a poor choice for timer when time accuracy is important, because, well,
> it's simply not accurate. When my system was using tsc, I would notice
> time drift of almost 1 minute every hour. This seems to be considered
> 'ok' by people because you can just configure your computer to adjust
> clock daily with ntp. Asside from the problem that tsc time will drift
> depending on your system load, if you have a multi-core system, tsc will
> drift from itself on different cores. Some multi-core cpu's will
> synchronize tsc (I think the Intel Core 2 series, for example, but don't
> quote me),, whereas other CPU's will lead to tsc being unstable and the
> system switching to something else. (although, this should all happen
> automagically, a system throwing a hairball over it should be considered
> a bug.)
>
Thanks Rashkae!

I had tried at an earlier date to use the kernel load line to load acpi
as the default clocksource, as that is the name it appears under in my
log files, but it didn't work as I did not know the full name was
actually acpi_pm. Now that I've used your command to ferret out the
actual name, and also with the help of your tutorial here in this thread
I can now change it over.

After reading the links provided in this thread, I'm wondering if it
would even be that big of a deal on my system for tsc to remain enabled,
as I have only a single core cpu, so it shouldn't suffer from the
synchronization problem like a multi core cpu, if I'm understanding the
problem correctly.

But then the system marks it unstable anyway, and switches to acpi, so
to get rid of the error message I'll change it over in menu.lst.

It would be difficult to slip very far out of time on here considering
how often my ntp daemon polls the time servers, which is every couple of
minutes. I haven't yet discovered how to control the frequency of those
polls. When running Windows on this T3410 Emachine I only have one daily
time server synchronization just after boot up, and it has always kept
time to within 30 seconds a day drift or often much less, so I wonder
what they are using for a clocksource?

Thanks again, Later, Ray Parrish

--
Human reviewed index of links about the computer
http://www.rayslinks.com
Poetry from the mind of a Schizophrenic
http://www.writingsoftheschizophrenic.com/


--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 02-28-2009, 01:30 AM
NoOp
 
Default Kernel clock issue "Clocksource tsc unstable"

On 02/27/2009 12:39 PM, Rashkae wrote:
> Ray Parrish wrote:
>
>> Hello,
>>
>> Sorry to butt in here, but I also receive the error messages about
>> clocksource tsc being unstable. I ran the command for available
>> clocksources and got the following output. "acpi_pm pit jiffies tsc" My
>> system switches to acpi_pm after the error message, but I would like to
>> read about the other available clocksource files before making a
>> decision on which to try to use from the menu.lst file.

I have old laptops that use acpi_pm rather than tsc, but I sync the time
to an ntp server so I don't ever have any problems with them. Dmesg on
those read something along the line of:
Clocksource tsc unstable(deslta = -87685142 ns)

>
> Sorry, this is really deep magic stuff where mortals were really never
> meant to thread. You practically have to dig through the kernel source
> to find any scraps of useful information. I just got a crash course
> about 6 months ago when I was trying to solve a clock drift issue. I'll
> try to provide the cliff notes, but keep in mind, this is just my
> understanding of things and I might be wrong about a fact or 2.

I recall that thread:
http://comments.gmane.org/gmane.linux.ubuntu.user/145397
[Computer loosing time]
might be worth looking at again.

[snips rest of excellent info]

I wonder if perhaps when Hal reboots his machines the reason why the
clocks/dates get readjusted properly is because the boot causes the
ntpdata script to run:

/etc/network/if-up.d/ntpdate

and hence resync?

@Hal: next time, instead of rebooting (you'll still have to go to the
data center most likely), you might try
sudo /etc/network/if-up.d/ntpdate
first. If that resyncs the machine properly without the reboot, then you
might want to look into running ntp on those machines if you aren't
already. And if you are running ntp, have a look at the ntp source. You
can elect to have multiple sources; I use 0.us.pool.ntp.org and have
1.us.pool.ntp.org as the backup. Just a thought...








--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 

Thread Tools




All times are GMT. The time now is 07:31 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org