Bug 7242 - got a time machine, my time runs about 30times faster than it should
got a time machine, my time runs about 30times faster than it should
Status: CLOSED CODE_FIX
Product: Timers
Classification: Unclassified
Component: Realtime Clock
i386 Linux
: P2 high
Assigned To: john stultz
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-01 05:50 UTC by Alexander Krause
Modified: 2006-10-22 18:55 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.18
Tree: Mainline
Regression: ---


Attachments
dmesg output 2.6.17.13 (5.87 KB, text/plain)
2006-10-01 11:25 UTC, Alexander Krause
Details
dmesg output 2.6.18 (5.99 KB, text/plain)
2006-10-01 11:27 UTC, Alexander Krause
Details

Description Alexander Krause 2006-10-01 05:50:15 UTC
Most recent kernel where this bug did not occur:
  * 2.17.13

Hardware Environment:
  * WRAP-board, Geode

Software Environment:
  * busybox-1.1.2
  * uclibc-0.9.28
  * kernel-setup:
    * <*> Enhanced Real Time Clock Support
    * Real Time Clock/< > RTC class

Problem Description:
RTC seems to be broken, using `date` to get my date looks like this:
Geode ~ $ date
Sun Oct  1 22:27:34 CEST 2006
*wait 1 second*
Geode ~ $ date
Sun Oct  1 22:28:03 CEST 2006

This also affects all time related functions like sleep, watch and so on.
Comment 1 Andrew Morton 2006-10-01 10:54:32 UTC
argh, not this again.

Please include the full `dmesg' output.

Please clarify the "Most recent kernel where this bug did not occur".  You say
2.17.13, but there's no such kernel version.
Comment 2 Alexander Krause 2006-10-01 11:25:28 UTC
Created attachment 9144 [details]
dmesg output 2.6.17.13
Comment 3 Alexander Krause 2006-10-01 11:27:50 UTC
Created attachment 9145 [details]
dmesg output 2.6.18

there are some errors at the end like:
<4>TSC appears to be running slowly. Marking it as unstable
<6>Time: scx200_hrt clocksource has been installed.
Comment 4 Alexander Krause 2006-10-01 11:28:55 UTC
> You say 2.17.13, but there's no such kernel version.
Damn... I'll never write kernel-versions by hand... I'll do a copy&paste job 
next time!
Well, i meant 2.6.17.13 of cause - sorry for that.
Comment 5 john stultz 2006-10-02 17:37:44 UTC
Hmmmm. I'll ping Jim Cromie (he wrote the scx200_hrt code) and see if he has a
clue if it is safe for this hardware.

Alexander: Does booting w/ clock=tsc work around this issue?
Comment 6 Jim Cromie 2006-10-02 21:45:39 UTC
Alex: pls add 'mhz27=1' to your modprobe and report.  Ive had 1 other report
where this apparently fixed things.  Also, please supply your
/sys/devices/system/clocksource/clocksource0/* values, and confirm effects of
using clock=tsc on bootline, and of the modprobing.

Others, pls comment: May be an off-by-1 err in request_region's size (5, should
be 6).  5 excludes TMCNFG reg, which has mhz27 flag.  Would writing 1 byte past
the region manifest an err message, be silently ignored, or silently succeed ??
Comment 7 Alexander Krause 2006-10-03 01:10:38 UTC
>Alexander: Does booting w/ clock=tsc work around this issue?
Actually not and it looks like it's about 20 times slower than normal (seconds 
on date output don't change).

With that kernel option enabled:
?> cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
scx200_hrt jiffies tsc pit 

?> cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
tsc 

I added 'clock=scx200_hrt scx200_hrt.mhz27=1' to my kernel and now things look 
good for me.

?> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
scx200_hrt 
Comment 8 Alexander Krause 2006-10-03 01:16:31 UTC
BTW some interesting dmesg lines with my current setup ( clock=scx200_hrt 
scx200_hrt.mhz27=1 )

<6>enabling scx200 high-res timer (27 MHz +0 ppm)
...
<6>Time: scx200_hrt clocksource has been installed.
...
<4>TSC appears to be running slowly. Marking it as unstable
Comment 9 Jim Cromie 2006-10-03 08:26:02 UTC
hi Alex,  Those 3 lines you quoted (entry #8) are expected.  But in #7 you
showed tsc being used.  That implies that #7 did not detect 'running slowly',
hence tsc was preferred.  Had it been detected, you would have fallen back to
either scx200_hrt, or finally PIT.  Is the detection somewhat unreliable on your
box ?
Comment 10 Alexander Krause 2006-10-03 11:02:34 UTC
>But in #7 you showed tsc being used.
>That implies that #7 did not detect 'running slowly',hence tsc was preferred.
I used clock=tsc at boot-time in #7 as suggested.

>Had it been detected, you would have fallen back to either scx200_hrt, or 
finally PIT.
>Is the detection somewhat unreliable on your box ?
Well, I'm not quite sure how the kernel should behave but when 
using 'clock=tsc', tsc seems to be forced.
Even though I'm getting '<4>TSC appears to be running slowly. Marking it as 
unstable'.

?> cat /sys/devices/system/clocksource/clocksource0/current_clocksource 
tsc 

Normaly it uses scx200_hrt and does not detect errors in that module.
Comment 11 Alexander Krause 2006-10-03 11:59:18 UTC
Jim, i got you mail some hours ago and i've tested you patch right now.

I'm booting without any clock-related kernel parameters and things are looking 
quite nice atm.

Thanks a lot ;-)
Comment 12 john stultz 2006-10-22 18:55:02 UTC
This should be fixed w/ the current -git. Please reopen if that's not the case.

Note You need to log in before you can comment on or make changes to this bug.