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.

Проблема не наблюдается.