| 47 | == Fixes if synchronisation fails == |
| 48 | |
| 49 | For a long time the default kernel clocksource has been tsc, but it used to be acpi_pm. On one of my machines, in one kernel release, I lost synchronisation and the log showed: |
| 50 | {{{ |
| 51 | frequency error 1726 PPM exceeds tolerance 500 PPM |
| 52 | }}} |
| 53 | |
| 54 | Google found a not-too-old link to redhat [https://access.redhat.com/solutions/35640] which suggested checking the available drivers with |
| 55 | {{{ |
| 56 | cat /sys/devices/system/clocksource/clocksource0/available_clocksource |
| 57 | }}} |
| 58 | and assuming that acpi_pm is available, temporarily changing to it with |
| 59 | {{{ |
| 60 | echo acpi_pm >/sys/devices/system/clocksource/clocksource0/current_clocksource |
| 61 | }}} |
| 62 | and seeing if that helps. If useful, it can forced by adding |
| 63 | {{{ |
| 64 | clocksource=acpi_pm |
| 65 | }}} |
| 66 | to the bootargs in grub. |
| 67 | |
| 68 | == When the clock is too far away from the correct time == |
| 69 | |
| 70 | If ntpd bails out because the clock is too far from the correct time, try stopping ntpd, using |
| 71 | {{{ |
| 72 | ntpd -gq |
| 73 | }}} |
| 74 | to let it sync, and then restarting ntpd. According to the man page, -g can be used multiple times if the clock is far adrift. |
| 75 | |
| 76 | |
| 77 | |
| 78 | |
| 79 | |
| 80 | |