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.
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.
Created attachment 9144 [details] dmesg output 2.6.17.13
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.
> 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.
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?
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 ??
>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
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
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 ?
>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.
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 ;-)
This should be fixed w/ the current -git. Please reopen if that's not the case.