F10: Clocksource tsc unstable (delta = 4398046246492 ns)

[Isaac1357]

I've got an HP Pavilion dv9000 laptop, on which I was running Fedora 9 with no problems. I did a clean install of Fedora 10 (x86_64), and now I'm getting a kernel error on boot. The error is:

Clocksource tsc unstable (delta = 4398046246492 ns)

What is really bizarre is that it will sit there and hang forever unless I hit a key on the keyboard a few times, but once I do it boots normally. The system remains stable after getting past the weirdness on boot, so it seems to be more an annoyance than anything else.

I googled and found some forum entries recommending appending "clocksource=hpet" to the kernel line in grub, but that didn't seem to have any effect at all.

The system has a Turion64 X2 TL58 CPU, and an Nvidia MPC67 chipset.

Here's my hardware profile.

Anyone have any ideas?

[shess01]

Google turns up quite a few pages regarding "Clocksource tsc unstable". Something to do with acpi and some kernel options, and is mainly discussed in the mailing lists so checking there you may find an answer - instead of the sound of crickets chirping....

Although this link is kind of old, some posters claim a to have solved their issue here.
http://kerneltrap.org/?q=node/8306

Please post back if you find the solution. Good luck.

[Isaac1357]

None of the clocksource=[hpet,rtc,acpi_pm] options seem to do anything, nor does notsc. I still get the "clocksource tsc unstable" errors with any of those options as well as the hangs.

acpi=off does solve the problem, but this is a laptop and turning acpi off completely isn't really ideal, since it disables CPU frequency scaling completely. I'll keep it off for the moment and either wait for the next F10 kernel updates to see if that fixes anything, or I may just roll my own kernel and see if I can find the magic options that work properly.

I know that the laptop can work normally under Linux, since it ran flawlessly under F9 with acpi on. I suppose I could always downgrade back to F9, but I'd rather not.

[Martin Blank]

I've got an Inspiron 1720 that is doing the same thing, though acpi=off doesn't seem to make any difference. Did you change anything in the BIOS that may have assisted in getting it to work?

[Isaac1357]

No, I didn't change any BIOS settings. I looked around in there, but on this laptop basically the only thing you can change is boot order, shared video memory, and boot/cmos password.

Just curious, are you running 32 or 64 bit? I haven't checked to see if this is a problem on the 32 bit version of F10 or not, and am wondering if this happens on both.

UPDATE: found the option "clocksource=jiffies" this fixed it for me without turning acpi completely off. Found, at shess's link above the following command:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

which shows what clocksources are currently available on your system.

Martin, what do you get from the cat command above?

[Martin Blank]

I'm running 64-bit as well. Checking clocksources, I get hpet, acpi_pm, jiffies, and tsc, and current (under the rescue disc) is hpet. None of those work setting them in the kernel line.

What frustrates me is that the DVD boots just fine into rescue mode, using exactly the same kernel. It makes me wonder if there's some issue with the encrypted partition. I'm tempted to decrypt it and see if that fixes it.

[Isaac1357]

If you're able, try turning acpi off in the BIOS and see if it boots properly, or just frequency scaling if that's an option. I know it's not the ideal fix, but it may work until a better fix is available. Also, check what kernel options the DVD is using to boot with and see if anything is different.

[scottro]

Yes, google turns up several things, most of them with the comment that it won't necessarily work.

Various things to try clocksource=hpet, also trying noapic nolapic.

I haven't had this happen with me in Fedora--I've actually only seen it in some fringe distros that I would play with--however, I'm ruthless with those, if they're not going to even boot without problem, I don't even try.

[Martin Blank]

Can't turn off ACPI in the BIOS, and the grub.conf in /isolinux on the DVD only has the following:

#debug --graphics
default=0
splashimage=/EFI/boot/splash.xpm.gz
timeout 5
hiddenmenu
title @PRODUCT@ @VERSION@
	kernel /EFI/boot/vmlinuz
	initrd /EFI/boot/initrd.img

I've tried clocksource=hpet, and I've tried noapic and nolapic, alone and in combination. They don't work. In the last few lines, I see that it's creating /dev, and it defines the keyboard and touchpad, then goes looking for the keymap. And that's about as far as I get.

[Martin Blank]

I am left wondering if this doesn't have something to do with the EFI stuff. I'm not sure if that's completely applicable here.

[josealb85]

hi i use this config and solves then hang issue, but still wait 10 seconds for stabilization

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=3
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Fedora (2.6.27.5-117.fc10.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.27.5-117.fc10.x86_64 ro clocksource=jiffies root=UUID=9ec6d017-8401-48e2-a52d-de21f03c7e7c rhgb quiet
initrd /initrd-2.6.27.5-117.fc10.x86_64.img

[DS_AOE]

In fact, I think this has to do with the Synaptics driver in the kernel.

If you look in /etc/X11, you may find a file called Xorg.conf (or xorg.conf). The setting SHMConfig = on causes the kernel to try to grab a clock suitable for timing touchpad activity, I think.

In any event, deleting this file allowed my system to boot 100% normally.

I discovered the problem in trying to get the Synaptics Touchpad widget to work - before playing with the widget and associated files, my system was bulletproof. One slight change to the Xorg.conf file and suddenly I got the Clocksource tsc unstable error.

I hope this cross-posts to developer forums but I will try and submit a bug report anyway.

Happy linuxing

Dave

[jenaniston]

In fact, I think this has to do with the Synaptics driver in the kernel.

If you look in /etc/X11, you may find a file called Xorg.conf (or xorg.conf). The setting SHMConfig = on causes the kernel to try to grab a clock suitable for timing touchpad activity, I think.

In any event, deleting this file allowed my system to boot 100% normally.

. . . One slight change to the Xorg.conf file and suddenly I got the Clocksource tsc unstable error.

good to know and pass on to laptop users with touchpads . . . even with an optical mouse plugged in USB port.

While the available and the current clocksource in use are listed respectively in . . .
/sys/devices/system/clocksource/clocksource0/available_clocksource
and
/sys/devices/system/clocksource/clocksource0/current_clocksource

Does anyone know if other clocksources can be made available to the kernel and maybe loaded in - are these like a module or similar ?

Thanks.