ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | the system clock runs too slow on some kernels > 2.6.18 | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Ivan Zakharyaschev <imz> | ||||||||||||||||
| Component: | kernel-image-std-def | Assignee: | Vitaly Chikunov <vt> | ||||||||||||||||
| Status: | CLOSED WORKSFORME | QA Contact: | qa-sisyphus | ||||||||||||||||
| Severity: | normal | ||||||||||||||||||
| Priority: | P2 | CC: | kernelbot, placeholder, vt | ||||||||||||||||
| Version: | unstable | ||||||||||||||||||
| Hardware: | all | ||||||||||||||||||
| OS: | Linux | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Ivan Zakharyaschev
2008-01-31 08:22:01 MSK
Hardware time remains correct. The system time runs too slow. I reproduced the experiment on 2.6.24-wks-smp-alt0.8: I set the time to the correct time at about Jan 31 08:52. hwclock; date gave: Thu Jan 31 05:52:48 2008 -2.115300 seconds MSK Thu Jan 31 08:52:46 MSK 2008 No significant difference (/etc/adjtime was removed, that's the reason for the 3 hours difference). Now, about 2 days later: # date; hwclock; date Sat Feb 2 12:10:32 MSK 2008 Sat Feb 2 09:18:45 2008 -2.339343 seconds MSK Sat Feb 2 12:10:34 MSK 2008 # The difference is about 8 minutes. The hardware clock is close to the correct time. The same on 2.6.24-wks-smp-alt1: uptime 1 day, 3:57, the difference is more than 4 minutes: # date; hwclock ; date Sun Feb 3 17:06:56 MSK 2008 Sun Feb 3 17:11:24 2008 -0.353278 seconds MSK Sun Feb 3 17:06:56 MSK 2008 # The hardware clock is close to the correct time. the same on 2.6.22-wks-smp-alt0.6: uptime 1 day, 11:07; the difference between clocks is about 6 min., the clock close to the correct time is the hardware clock: # date; hwclock ; date Tue Feb 5 04:42:27 MSK 2008 Tue Feb 5 04:48:05 2008 -3.010491 seconds MSK Tue Feb 5 04:42:30 MSK 2008 # So, I wasn't right in the initial report that this bad behavior correlates with the CPU not entering "inactive" Cn states under a certain kernel. (This is one of such kernels I've tested -- I look at the Cn states in powertop.) $ rpm -q kernel-image-wks-smp-2.6.22-alt0.6 -i Name : kernel-image-wks-smp Relocations: (not relocateable) Version : 2.6.22 Vendor: ALT Linux Team Release : alt0.6 Build Date: Пнд 12 Ноя 2007 03:24:35 Install date: Втр 13 Ноя 2007 20:17:24 Build Host: lakostis.hasher.altlinux.org Group : System/Kernel and hardware Source RPM: kernel-image-wks-smp-2.6.22-alt0.6.src.rpm Size : 48268215 License: GPL Packager : Konstantin A. Lepikhov <lakostis@altlinux.ru> <...> Can you attach the archive generated by system-report utility (it can be found in branch/4.0 and Sisyphus)? I'm need the dmidecode results and /proc/dsdt contents. This bug is not present in 2.6.18-std-smp-alt8: uptime: up 17:30 no significant divergence between the clocks: # date; hwclock ; date Tue Feb 5 23:01:55 MSK 2008 Tue Feb 5 23:01:54 2008 -0.125768 seconds MSK Tue Feb 5 23:01:56 MSK 2008 # Created attachment 2416 [details] sysreport-20080206.tar.bz2 (In reply to comment #4) > Can you attach the archive generated by system-report utility (it can be found > in branch/4.0 and Sisyphus)? (In reply to comment #4) > and /proc/dsdt contents. I have no /proc/dsdt. (In reply to comment #7) > (In reply to comment #4) > > and /proc/dsdt contents. > > I have no /proc/dsdt. > sorry, /proc/acpi/dsdt of course. Created attachment 2417 [details]
/proc/acpi/dsdt
Does the situation is changed when you try to pass the clocksource=tsc or clocksource=acpi_pm in kernel cmdline? PS please post the /proc/timers_list contents. Created attachment 2418 [details]
/proc/timer_list
Created attachment 2419 [details]
dmesg output (2.6.24-wks-smp-alt1+acpi_pm)
2.6.24-wks-smp-alt1 + clocksource=acpi_pm -- no changes, uptime: 51 min, the
clocks:
# date; hwclock ; date
Wed Feb 6 04:20:59 MSK 2008
Wed Feb 6 04:21:08 2008 -0.607247 seconds MSK
Wed Feb 6 04:20:59 MSK 2008
#
So, the drift is about -10 sec per 1 hour, the same as it was.
(Going to test clocksource=tsc, will report results tomorrow.)
Created attachment 2420 [details]
/proc/timer_list (2.6.24-wks-smp-alt1+acpi_pm)
Created attachment 2422 [details]
dmesg output (2.6.24-wks-smp-alt1+tsc)
2.6.24-wks-smp-alt1 + clocksource=tsc -- again this effect, uptime: 12:52, the
clocks:
# date; hwclock ; date
Wed Feb 6 17:42:18 MSK 2008
Wed Feb 6 14:44:48 2008 -0.910568 seconds MSK
Wed Feb 6 17:42:19 MSK 2008
#
So, the drift is a bit more than -10 sec per 1 hour.
Created attachment 2423 [details]
/proc/timer_list (2.6.24-wks-smp-alt1+tsc)
Some strange effects of clocksource=tsc seen in the system init sequence: https://bugzilla.altlinux.org/show_bug.cgi?id=14343 , https://bugzilla.altlinux.org/show_bug.cgi?id=14345 . This effect is not observed on 2.6.24-std-def-alt2: uptime: 7:23 (7 hrs 23 min) # date; hwclock ; date Thu Feb 7 03:23:03 MSK 2008 Thu Feb 7 03:23:01 2008 -0.000387 seconds MSK Thu Feb 7 03:23:04 MSK 2008 # (So, on this kernel the system clock is a tiny bit too fast, not slow.) Out of curiosity, I tested also 2.6.24-std-def-alt2 with clocksource=tsc. And the effect is present, even in a stronger form: uptime: 1:20 # date; hwclock ; date Thu Feb 7 04:48:39 MSK 2008 Thu Feb 7 01:49:44 2008 -0.000381 seconds MSK Thu Feb 7 04:48:39 MSK 2008 # So, the drift is about -1 min per 1 hour. (But of course I don't consider this as a serious bug because this is present not under the default kernel parameters.) (In reply to comment #17) > This effect is not observed on 2.6.24-std-def-alt2: uptime: 7:23 (7 hrs 23 min) > # date; hwclock ; date > Thu Feb 7 03:23:03 MSK 2008 > Thu Feb 7 03:23:01 2008 -0.000387 seconds MSK > Thu Feb 7 03:23:04 MSK 2008 > # > > (So, on this kernel the system clock is a tiny bit too fast, not slow.) It's a good sign :) Because current wks-smp based on 2.6.24-rc8 we have all chances that new release will doesn't have this bug (std-def based on vanilla 2.6.24). Please, test this behavior when new wks-smp appeared in Sisyphus. (In reply to comment #19) > 2.6.24). Please, test this behavior when new wks-smp appeared in Sisyphus. Please let me know when there is a version to test. (In reply to comment #20) > (In reply to comment #19) > > 2.6.24). Please, test this behavior when new wks-smp appeared in Sisyphus. > > Please let me know when there is a version to test. You can try new version of wks kernel from http://www.unsafe.ru/lakostis/RPMS/ALTLinux/kernel-2.6.26 and report about new behavior. Reassing to actual kernel in Sisyphus. Feel free to check this issue on std-def kernel. Проблема не наблюдается. |
