Clocksource tsc unstable add 10 seconds to the boot time.

Bug #190414 reported by Saivann Carignan on 2008-02-09
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description

This bug happens on a Dell inspiron 9300 laptop at boot with ubuntu Hardy Alpha 4, linux-image-2.6.24-7-generic (i386).

At boot, I get a 10 seconds with usplash bar going left to right and right to left, freezing. When I start the computer without usplash, I saw that the boot process abnormally stops for 10 seconds on these two ata1 and ata2 outputs :

[ 32.938344] scsi1 : ata_piix
[ 32.939068] ata1: SATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xbfa0 irq 14
[ 32.939119] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xbfa8 irq 15
[ 33.081820] Clocksource tsc unstable (delta = -26289008726 ns)

This problem did not happen with dapper/edgy/feisty/gutsy

Saivann Carignan (oxmosys) wrote :
Saivann Carignan (oxmosys) wrote :
Saivann Carignan (oxmosys) wrote :
Saivann Carignan (oxmosys) wrote :
Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: New → Triaged
Stéphan Kochen (stephank) wrote :

I'm seeing a similar problem on a NEC Versa P550, but it actually turns out to be the TSC clock source that's causing the trouble in my case.

Right after that "Clocksource tsc unstable" message in your dmesg output, you'll notice the kernel detects the problem and switches to another clock source:
"Time: hpet clocksource has been installed."

You can tell it to use the HPET clocksource from the start by adding "clocksource=hpet" to your kernel command line. The kernel command line is specified in /boot/grub/menu.lst at the line starting with "# kopt=...".

See if that fixes your problem. :)

Saivann Carignan (oxmosys) wrote :

I confirm that boot with clocksource=hpet fixes that problem. However, I still see usplash bar going left to right and right to left for a 2 seconds, I'm not sure that it is normal since it didn't happen wth gutsy. Thanks for the workaround!

Saivann Carignan (oxmosys) wrote :

Still happening with Hardy a5, linux-image-2.6.24-8-generic

Saivann Carignan (oxmosys) wrote :

Still happening with Hardy a5, linux-image-2.6.24-10-generic

William Grant (wgrant) wrote :

I have the same issue on my Dell Inspiron 630m (with the same clocksource messages) with -11. The two pauses add up to some 35 seconds.

Giovanni Condello (nanomad) wrote :

Here is 2 videos as a .tar.gz archive (mp4 format, taken with my smartphone) that show the bug:
(the video will be deleted when it has not been accessed for more than 90 days)
Attached are some logs. More will be added tomorrow morning (dmesg and version_signature)

Saivann Carignan (oxmosys) wrote :

Still happening with Hardy a6, linux-image-2.6.24-12-generic

nappsoft (pirmin) wrote :


I seem to have a similar problem (linux-image-2.6.24-12-generic)· But for me the timeout is much bigger, more than one minute. This happens just at the beginning of the boot-process. Will have to boot without boot-splash to give more information.

I updated 7.10 to hardy today. Before I was already running 7.10 with a self-compiled 2.6.24 kernel (with tuxOnIce support) without any problems. Even after the update this kernel works without timeouts at boot-up, this happens only with the ubuntu-kernel.

nappsoft (pirmin) wrote :

So here is some more information from my side. The system hung for more than 5 minutes today. After that I stopped the boot-process and booted with my self-compiled 2.6.24 kernel.

Here the last output:

scsi0: ata_piix
scsi1: ata_piix
ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1810 irq 14
ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15

Have a look at my 2.6.24-Config (didn't spend time on optimizing it, just wanted TuxOnIce-Support).

nappsoft (pirmin) wrote :

Still the same with linux-image-2.6.24-14-generic

nappsoft (pirmin) wrote :

A few more observations:

- As mentioned my old 2.6.24 was working with hard while the hardy kernel didn't work

So I tried with my 2.6.24 config, which worked. Then I tried it with config-2.6.24-14-generic what didn't work... Most of the time the system did not even boot (the same as with the official 2.6.24-14-generic kernel). The place where it stopped booting was always the same (have a look at my second-last message).

At the end I found out why my old 2.6.24 config did work and the new didn't: Using config-2.6.24-14 and changing CONFIG_M586 to CONFIG_MPENTIUMM (in Menuconfig what changes in fact a few other values, see at the full diff later).

So I think that this is not a ubuntu specific bug as the Gutsy-CONFIG_M586.kernel was working on the same machine without any problems... Even though I think that this is an important bug as my Samsung notebook uses the same components as many other centrino notebooks and I doubt that only a few machines are affected...

Saivann Carignan (oxmosys) wrote :

nappsoft : Thanks a lot for all the informations you provide. I suspect that your bug is not the same as the one initially described. According to what you say, your computer takes more than 5 minutes to boot (or does not boot at all) and your problem does not seem to be caused by tsc clocksource like this bug. Therefore, to help both bug reports to get fixed, can you open a new bug report for linux package with a detailed description and the informations that you already provided? Can you also attach separate files created by these commands on a terminal and assign the bug to the ubuntu kernel team?

    * uname -a > uname-a.log
    * cat /proc/version_signature > version.log
    * dmesg > dmesg.log
    * sudo lspci -vvnn > lspci-vvnn.log

nappsoft (pirmin) wrote :

Saïvann: Of course you're right. When I started adding comments here and did not yet have that much information the bug seemed to be similar to #197228 which was marked as beeing the same as this one. For sure the troubles I have seem to be more serious and not be caused by the same module even though it's happening almost at the same place during boot-up.

Sorry for spamming this entry. I've opened a new bug-report as requested. The number for this bug is #211589.

Alessio Igor Bogani (abogani) wrote :

Could you try to boot with notsc option?


nappsoft (pirmin) wrote :

Booting with notsc helps indeed not stopping at this place, but the troubles follow later! While my system runs perfectly with a pentium-m kernel it isn't working even with the notsc boot-option using the ubuntu-kernel.

Now I get 100% cpu and the following messages:

init[1] general protection eip:b7f15a23 asp:bfd5faf4 error:0
printk: 5659008 messages suppressed

and so on...

Amit Kucheria (amitk) wrote :

and with 'clocksource=hpet' ?

Changed in linux:
assignee: ubuntu-kernel-team → amitk
Saivann Carignan (oxmosys) wrote :

As said previously, clocksource=hpet works correctly for me.

nappsoft : Can your confirm the same?

nappsoft (pirmin) wrote :

yes clocksource=hpet is working. I'm sorry, it seems like I'd missed Stéphan Kochen's post!

So there are 3 options to get it to work:

- clocksource=hpet
- compiling the kernel for pentium-m instead of 586
- using 2.6.25 (works as 586 kernel without the clocksource=hpet option)

pixolex (pixolex) wrote :

I had the same problem, but not any more, and don't no why?!?

I made the clocksource=hpet trick and erased the QUIET option in the kernel line at grub, every thing worked ok...not the 30 sec infinite waiting any more...

But now i have every thing by default and the 30 sec waiting IS GONE, like it never happen!! Why?

Does the kernel healed it self after the clocksource thing?

Saivann Carignan (oxmosys) wrote :

This bug can still be reproduced here in Hardy with all updates.

pixolex : You probably added clocksource=hpet in your /boot/grub/menu.lst file, so it is used each time your computer boot or it is fixed for some hardwares only, but I really doubt that it's the case.

pixolex (pixolex) wrote :


I added clocksource=hpet and erased "quiet" and after some normal reboots removed the clocksource=hpet and added the "quiet" (in the menu.lst of course)

Now, the same problem again. But just simply removed the "quiet" from the boot line in the menu.lst and every thing is normal.

What the hell trigger the problem??

pjina3 (pjina3) wrote :

I have the same problem but the two last lines are :
- b43legacy-phy0: Broadcom 4301 WLAN found
- Clocksource tsc unstable (delta = 4687308187 ns)

 I try to add the option "clocksource=hpet" but it not solve the problem :(


Is there a line below the "tsc unstable" one? It should tell you what clocksource it's selecting instead, which is the one you should be picking - it won't necessarily be hpet. Boot without the clocksource or quiet arguments and see what it says.

pjina3 (pjina3) wrote :

Benjamin Rader:

No, there is'nt but i will try to do that :)

ps. I thinks the bugs below seem to be a duplicate

[URL=""]bug #1219498[/URL]
[URL=""]bug #192720[/URL]
[URL=""]bug #218256/URL]
[URL=""]bug #220384[/URL]

Saivann Carignan (oxmosys) wrote :

pjina3 : The bug that you have is bug 192720 which is caused by b43legacy. All these bugs were duplicates of this one. Thank you for finding them!

nappsoft (pirmin) wrote :

Still happens with 2.6.24-17 without clocksource=hpet (as mentioned above: doesn't happen with 2.6.25)

Philipp Kohlbecher (xt28) wrote :

I think the problem is that "CONFIG_X86_TSC" is not set in the kernel configuration. If it were, the idle functions in drivers/apci/processor_idle.c would mark the TSC as unstable, preventing this bug.

Aitor Pazos (aitorpazos) wrote :

clocksource=hpet prevents kernel panic on my Latitude D420.
but something is still happening because in the same situation I loose my right mouse button. After restarting xserver everything works well again, until I let my laptop go idle again, where I loose my right button again. Symptom are the same but without kernel panic (mouse and sound seems to freeze for some seconds).

These are the messages that it drops in /var/log/messages:
May 6 12:52:45 Apidell kernel: [ 1010.005914] psmouse.c: GlidePoint at isa0060/serio1/input0 lost synchronization, throwing 3 bytes away.
May 6 12:52:47 Apidell kernel: [ 1013.670465] psmouse.c: resync failed, issuing reconnect request
May 6 12:52:48 Apidell kernel: [ 1012.888370] input: PS/2 Mouse as /devices/virtual/input/input14
May 6 12:52:48 Apidell kernel: [ 1012.948570] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input15
May 6 12:57:19 Apidell kernel: [ 1283.718087] input: PS/2 Mouse as /devices/virtual/input/input16
May 6 12:57:19 Apidell kernel: [ 1283.766062] input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input17

erythrocyte (erythrocyte) wrote :

I have Kubuntu 8.04 Hardy Heron (KDE 3.5.9) and it has become dead slow (>4mins) at boot (at the "reading files needed to boot" stage) after a couple of updates a few days ago. Adding clocksource=hpet to my kernel line hasn't solved this at all. I've opened up a thread at with some debug info. Could someone please take a look and see if I need to file a new bug report? I'm a total noob and would really appreciate any help in solving this. Thanks a ton!

Linard Verstraete (linardv) wrote :

Kernel 2.6.24-17 is avaiable in the "Update Manager".
Part of the changelog: * TSC Clocksource can cause hangs and time jumps - LP: #221351

It seems related to this bug, can the people here update to the new kernel and test for themselves if it solves the bug they are experiencing?

Saivann Carignan (oxmosys) wrote :

I tested 2.6.24-17 on my laptop and the bug is still here, TSC Clocksource is still unstable at boot and add several seconds before it is replaced by hpet.

nappsoft (pirmin) wrote :

2.6.24-17 doesn't work for me without clocksource=hpet. See my message from 2008-05-04.

Didn't fix it.

If anything, 2.6.24-17 made it worse. It froze during startup (as
before), generating interrupts by tapping keys or moving the mouse
didn't seem to make a difference, when I performed a soft reboot by
pressing Ctrl-Alt-Delete, my computer could no longer get through the
BIOS stage, probably because of some issue with the hard disk. It now
works fine after a hard reboot and providing the "clocksource=hpet"
command line option. Whether the hard disk thing has anything to do with
the new kernel version, I don't know. But it certainly did not fix the
clocksource issue.

Aitor Pazos (aitorpazos) wrote :

Things are still the same for me with the new kernel.

Linard Verstraete (linardv) wrote :

Oké, thanks for confirming, it doesn't solve it for me either...

@nappsoft: Sorry, I have read over that one...

Philipp Kohlbecher (xt28) wrote :

Problem persists.

$ cat /proc/version
Linux version 2.6.24-18-generic (buildd@terranova) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Wed May 28 20:27:26 UTC 2008
$ cat /proc/version_signature
Ubuntu 2.6.24-18.32-generic

I've experienced the exact same thing on a HP 8510p.

I've attached my logs if anyone wants to look.

thecure (keith-k) wrote :

clocksource=hpet worked for me (Dell Inspiron 6000)

I have a Wubi install of Hardy Heron on my Sony Viao Z505HS.

Boot halts at Clocksource tsc unstable. I read the rest of this thread and the following list in my grub boot file.


It worked once, but only once. Now it fails again on the same line. I don't know why. The grub file has not changed or reverted. The change is still there.

Daëavelwyn (daeavelwyn) wrote :

I have exactly the same problem on my inspiron 1720 (core2duo) under ubuntu hardy 8.04 :

dmesg | grep "Clocksource"
[ 23.987505] Clocksource tsc unstable (delta = -26370003969 ns)

cat /proc/version
Linux version 2.6.24-18-rt (buildd@terranova) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP PREEMPT RT Wed May 28 23:38:58 UTC 2008

LI Daobing (lidaobing) wrote :

my dmesg log:

[953628.159139] Clocksource tsc unstable (delta = 4686637338 ns)
[953628.169116] Time: acpi_pm clocksource has been installed.

$ uname -a
Linux lab-95 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux

does it belongs to the same bug?

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.


2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Saivann Carignan (oxmosys) wrote :

Leann Ogasawara : I'm the initial bug reporter. I can confirm that this bug disappeared in 2.6.26.* and does not happen with 2.6.27 . According to this, I set the status to fix released. If anybody can reproduce this problem with intrepid, please set back the status of the bug report to "new".

Leann Ogasawara : At the same time, this bug is not fixed in Hardy. Do you think that it's worth adding a nomination for hardy? Some people reported crash problem, but in my case it was only a very long boot time.

Changed in linux:
status: Triaged → Fix Released

Hi Saivann,

Thanks for testing and the update. The issue with getting this fixed in Hardy would be isolating the exact patch(es) to backport. With the limited number of resources on the kernel team we'd likely need your help with performing a git bisect to isolate the patches. Then it's a matter of determining how intrusive the patches are and if they'd qualify for SRU. In the end, since you are the original bug reporter and the issue you've mentioned is just a 10sec delay in boot, I'd probably not count it as SRU worthy based on the criteria listed at .

This bug was a deal killer for putting Hardy on my laptop. I can try again when Intrepid comes out... When is that?

--- On Thu, 8/28/08, Leann Ogasawara <email address hidden> wrote:
From: Leann Ogasawara <email address hidden>
Subject: [Bug 190414] Re: Clocksource tsc unstable add 10 seconds to the boot time.
To: <email address hidden>
Date: Thursday, August 28, 2008, 2:14 PM

Hi Saivann,

Thanks for testing and the update. The issue with getting this fixed in
Hardy would be isolating the exact patch(es) to backport. With the
limited number of resources on the kernel team we'd likely need your
help with performing a git bisect to isolate the patches. Then it's a
matter of determining how intrusive the patches are and if they'd
qualify for SRU. In the end, since you are the original bug reporter
and the issue you've mentioned is just a 10sec delay in boot, I'd
probably not count it as SRU worthy based on the criteria listed at .

Clocksource tsc unstable add 10 seconds to the boot time.
You received this bug notification because you are a direct subscriber
of the bug.

Niels Egberts (nielsegberts) wrote :

Intrepid will release in Oktober 2008.

Saivann Carignan (oxmosys) wrote :

Leann Ogasawara : Thanks for your clear answer. Unfortunately, I won't have time/ressources/knowledge to look for the appropriate patch for Hardy so as you say, I think that having intrepid fixed will be enough. Workaround exist anyway and it's not a crasher bug. Thanks.

Grispa (grispa) wrote :

Hi everyone.

I tested Intrepid Ibex today on a Fujitsu Siemens amilo Xa 2528 (datasheet: ).

Besides other problems experienced with previous versions of Ubuntu, this time I had, during the boot, the "clocksource tsc unstable" message, followed by the complete boot stop..
Neither closcksource=acpi_pm nor closcksource=hpet were able to solve the problem.

I guess this bug is still here in Ibex..

Saivann Carignan (oxmosys) wrote :

Grispa : Can you open a new bug report for "linux" and describe your bug with more details?

Hi There,

I'm having this exact problem on Hardy Server, but this is fairly critical for me. The same error is logged:

Sep 20 10:22:25 host-01 kernel: [51281.289424] Clocksource tsc unstable (delta = 3323063740502 ns)
Sep 20 10:22:25 host-01 kernel: [51281.299403] Time: acpi_pm clocksource has been installed.
Sep 20 10:22:26 host-01 kernel: [51282.778316] NET: Registered protocol family 17

The problem here is once acpi_pm is installed the clock stays at that time as ntp seems to either be unable to update time or it constanly loses time and ntp manages to "hold" the time at the current time (Sep 20 10:22:26 in this case). This is a real showstopper as this causes all sorts of problems, Cacti graphs stop logging as it effectivly freezes in time as far as cacti is concerned and nagios/cron have problem scheduling things. The server (I've two that do this) both running 2.6.24-19-server become highly unstable, ssh logins fail, the system becomes highly unresponsive. I haven't pinned down when exactly this occured but it's basically rendered Hardy Server useless. It seems to have happened int he last couple of weeks but I'll be digging through the old logs to see... the problem being the logs are pretty useless with the time being completely off !

As regards changing clocksource the ones available are:
sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource
acpi_pm jiffies tsc

I'm trying jiffies as acpi_pm and tsc appear useless. The processor is a Intel(R) Xeon(TM) CPU 2.40GHz and it's Dell server, I'm afraid I'll have to update later on model numbers (it's a remote system) in case this is something hardware specific as I know both are the same, in fact so far a 3rd Server which is a HP proliant hasn't show same error.

I'd have to say I can't really wait for Ibex on this as the whole point of LTS Server is so it can sit there for 2 years or so till the next LTS. If you need and more info or want me to test anything then no problem.

- Félim

Ok well jiffies did not work, in cat when I switch ntp back on and ran date every 5 secs or so I get this:

user@host-01:~$ date
Sat Sep 20 10:22:51 BST 2008
user@host-01:~$ date
Mon Sep 22 05:40:35 BST 2008
user@host-01:~$ date
Mon Sep 22 05:40:35 BST 2008
user@host-01:~$ date
Mon Sep 22 05:40:35 BST 2008
user@host-01:~$ date
Mon Sep 22 05:40:35 BST 2008

where the actual time should have been 06:00 Hrs +

This also seems to lock up the machine, I've tried a remote reboot and while the ssh terminal was failry responsive some commands didn't seem to complete and had to be ctrl-C to quit. This is exactly what happened on the tcs/acpi_pm clocksource as well.

This is a Dell Poweredge 2800, what I've also read is forcing the CPU to stay at full speed can stop it which would be a ok temporary solution for me as it's more important the server works, but seems that scaling isn't available in Server ? Either that or it's handled differntly fromt he scaling governors like it was before:

user@host-01:~$ sudo ls -l /sys/devices/system/cpu/cpu0/
total 0
-r-------- 1 root root 4096 2008-09-22 11:43 crash_notes
drwxr-xr-x 2 root root 0 2008-09-22 11:42 topology
user@host-01:~$ sudo ls -l /sys/devices/system/cpu/cpu0/topology/
total 0
-r--r--r-- 1 root root 4096 2008-09-22 11:43 core_id
-r--r--r-- 1 root root 4096 2008-09-22 11:42 core_siblings
-r--r--r-- 1 root root 4096 2008-09-22 11:43 physical_package_id
-r--r--r-- 1 root root 4096 2008-09-22 11:43 thread_siblings

I've set clocksource=acpi_pm at boot to see if starting out on it rather than switching from TSC solves the issue, I'll update as soon as I have info. Just to add this never occurs right after or during boot, it can take several hours to occur. I haven't spotted a pattern yet but I'll keep my eyes open.

Attached Dmesg with acpi_pm enabled in grub.

Ok well that didn't fix it, despite acpi_pm enabled at boot it still seems to use TSC (Have to pardon my not understanding the inner workings of this) as I get the following:

Sep 22 12:03:57 host-01 kernel: [ 1007.064201] Clocksource tsc unstable (delta = 140599784626 ns)

It doesn't give me the switching to acpi_pm but the clock has already started to wander after being up for only a short while.

Grispa (grispa) wrote :

Exactly as reported here: .
This problem is present also in the Intrepid Ibex Alpha 6 release.

Ray Parrish (crp-cmc) wrote :


I have the same error as follows - these lines begin at line 438 of the file, which is nearly the end of it.

[ 117.926535] Marking TSC unstable due to: cpufreq changes.
[ 117.934315] Time: acpi_pm clocksource has been installed.
[ 118.140441] NET: Registered protocol family 10
[ 118.141179] lo: Disabled Privacy Extensions
[ 118.286247] Clocksource tsc unstable (delta = -179973678 ns)

When I added clocksource=acpi_pm to the menu.list entry for my newest kernel Ubuntu 8.04.1, kernel 2.6.24-22-generic, and rebooted, I was treated to a desktop where I was unable to get the drop down menu panel to drop down where I could use it, and the title bars and status bars of all applications were missing. I tried ALT-F2 for the Run command dialog, but that wouldn't come up, and ALT-F1 would not make the menu show either.

I was able to start a File Browser by clicking the Wine folder on the desktop, and from there was able to start a root terminal and capture the output of dmesg to file. Here is the same section from that file as is shown above from my more or less normal boot. - These start at line number 446 in the file.

[ 125.496519] Marking TSC unstable due to: cpufreq changes.
[ 125.852215] Clocksource tsc unstable (delta = -178014284 ns)
[ 126.007526] NET: Registered protocol family 10
[ 126.008274] lo: Disabled Privacy Extensions

I did find this line at line 238 of the file, which makes me wonder why TSC still tried to install later.

[ 26.594400] Time: acpi_pm clocksource has been installed.

I then removed the clocksource=acpi_pm from the menu.list file, and had to use the power button to shut down, and restart the computer. On this boot it came up normally again.

I have been having problems with every fifth boot or so leaving me in the condition that the menus will not drop down out of hiding, ever since I updated to this kernel. Once in a while it will happen on two boot ups in a row, and I will then boot to the next previous kernel which works right all the time.

I am attaching the output of the dmesg command for the boot up where the menus refused to drop down.

Thanks for any help you can be, Ray Parrish

jeko (jeko) wrote :


i got the same problem in my boot process. The message "Clocksource tsc unstable" blocked the booting for about 100 seconds and I had 2-3 else pauses after this... But I could solve the problem with a strange solution: I put the parameter


Line in menu.lst:
kernel /boot/vmlinuz-2.6.27-9-generic root=UUID=c6b5a1de-ce34-4618-b933-064490a2308e ro clocksource=tsc

and I had no pauses, instead of having 5-10 Minutes to boot I do now have 1 Minute or less. Maybe this makes no sense, but I encourage all of you who have this problem to try it out and report here if it worked...

Working with intrepid ipex.

I've got two logs attached, one before i made clocksource=tsc and one after it...

Hope it helps,
Dominique S.

jeko (jeko) wrote :

I also get this message during boot - but from what I read it's not a problem:

"As far as i know Pentium M processors have dynamically changed clock
speed (ofc to save power). That's why kernel notice that TSC is
unstable (it is indeed). [...] I don't think that there is an easy way to fix it (it is not even a
bug), time-stamp counter is not perfect..." [Pawel Dziepak]

Most laptops mentioned here do use a Pentium M (<- Centrino).

The tsc message still shows with 2.6.28-11-generic/Jaunty Alpha
[ 0.000000] Fast TSC calibration using PIT
[ 2.877852] Marking TSC unstable due to TSC halts in idle
[ 3.348014] Clocksource tsc unstable (delta = -412296801 ns)

Boot time tests (Acer 8106wlmi Pentium M 1.87Ghz):

Standard boot options: ~1:08
clocksource=tsc ~6:51 (I wouldn't want to use that)
clocksource=hpet ~1:08
clocksource=notsc ~1:08
acpi_pm ~1:08

Evan Carroll (evancarroll) wrote :

I'm reopening this bug, because of the continuous like-complaints on this issue. Before this bug is closed, we need to know what was fixed, and how those of us (myself) included can eliminate this "closed"-bug from the problems that we're observing.

Changed in linux (Ubuntu):
status: Fix Released → Incomplete
Amit Kucheria (amitk) wrote :

Un-assigning myself since I won't have time to work on this bug.

FWIW, there were many changes to the clock code around 2.6.24. All subscribers to this bug should file separate bugs because clocks are very HW/chipset specific. So even though they might appear to be the same problem, they might not be.

Changed in linux (Ubuntu):
assignee: Amit Kucheria (amitk) → nobody
Saivann Carignan (oxmosys) wrote :

I'm marking this bug back to Fix Released, as it is fixed for the initial reporter (me). In order to keep launchpad clean and to make sure that we don't mix different bugs, if anybody can still reproduce any issue, please open a new bug report including all relevant information you can give. If anybody can reproduce a problem that seems identical, it is still not the same bug has it is affecting different hardware, so it requires a special attention. Thanks!

Changed in linux (Ubuntu):
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers