Hi folks,
If I build a kernel for AMD Geode, then I see a clock drift of appr.
30 min. to 1 hour per day. If I build the same kernel for i486, then
the clock drift is gone. Running ntp makes no difference.
Hardware is a Linutop PC. /proc/cpuinfo says
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 10
model name : Geode(TM) Integrated Processor by AMD PCS
stepping : 2
cpu MHz : 0.000
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow
bogomips : 429.05
clflush size : 32
power management:
BTW, the CPU is running with 500 MHz (AFAIK). 0.000 MHz is surely not
correct. /proc/cpuinfo reports the same for both kernels.
Attached is the diff of the config files. Please mail if you are
interested in the complete config files, or if I can help to track
this down.
Regards
Harri
Harald Dunkel wrote:
> Hi folks,
>
> If I build a kernel for AMD Geode, then I see a clock drift of appr.
> 30 min. to 1 hour per day. If I build the same kernel for i486, then
> the clock drift is gone. Running ntp makes no difference.
>
> Hardware is a Linutop PC. /proc/cpuinfo says
>
> processor : 0
> vendor_id : AuthenticAMD
> cpu family : 5
> model : 10
> model name : Geode(TM) Integrated Processor by AMD PCS
> stepping : 2
> cpu MHz : 0.000
> cache size : 128 KB
> fdiv_bug : no
> hlt_bug : no
> f00f_bug : no
> coma_bug : no
> fpu : yes
> fpu_exception : yes
> cpuid level : 1
> wp : yes
> flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow
> bogomips : 429.05
> clflush size : 32
> power management:
>
> BTW, the CPU is running with 500 MHz (AFAIK). 0.000 MHz is surely not
> correct. /proc/cpuinfo reports the same for both kernels.
Hmm - we've heard reports of this before, but nothing came of it. I
would be interested in a chance to debug it this time.
Please try turning off CONFIG_GEODE_MFGPT_TIMER=y and try again. Also,
try something in the 2.6.28 family to rule out fixes in the timer subsystem.
Thanks,
Jordan
On Tue, Dec 2, 2008 at 10:36 AM, Harald Dunkel
<[email protected]> wrote:
> Hi folks,
>
> If I build a kernel for AMD Geode, then I see a clock drift of appr.
> 30 min. to 1 hour per day. If I build the same kernel for i486, then
> the clock drift is gone. Running ntp makes no difference.
For both configs, can you run:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
and:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
Then send back the output?
thanks
-john
john stultz wrote:
>
> For both configs, can you run:
> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> and:
> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>
> Then send back the output?
>
Sure. For 486:
% cat /sys/devices/system/clocksource/clocksource0/available_clocksource
pit jiffies
% cat /sys/devices/system/clocksource/clocksource0/current_clocksource
pit
For Geode (clock is running too fast):
% cat /sys/devices/system/clocksource/clocksource0/available_clocksource
jiffies
% cat /sys/devices/system/clocksource/clocksource0/current_clocksource
jiffies
dmesg says for Geode:
:
TSC: Unable to calibrate against PIT
TSC: No reference (HPET/PMTIMER) available
Marking TSC unstable due to could not calculate TSC khz
:
Regards
Harri
Hi Jordan,
Jordan Crouse wrote:
>
> Hmm - we've heard reports of this before, but nothing came of it. I
> would be interested in a chance to debug it this time.
>
> Please try turning off CONFIG_GEODE_MFGPT_TIMER=y and try again. Also,
> try something in the 2.6.28 family to rule out fixes in the timer
> subsystem.
>
> Thanks,
> Jordan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Dipl.-Ing. Harald Dunkel | "They that can give up liberty to obtain
Muehlenbachstr. 3 | a little temporary safety deserve neither
52134 Herzogenrath, Germany | liberty nor safety."
+49 2407 565 105 | Benjamin Franklin, 1706 - 1790
Hi Jordan,
Sorry for the empty reply. I clicked on [Send] by accident.
Jordan Crouse wrote:
>
> Hmm - we've heard reports of this before, but nothing came of it. I
> would be interested in a chance to debug it this time.
>
> Please try turning off CONFIG_GEODE_MFGPT_TIMER=y and try again.
AFAICS this was already set.
> Also,
> try something in the 2.6.28 family to rule out fixes in the timer
> subsystem.
>
The build is running, but it is a slow machine.
Regards
Harri
Harald Dunkel wrote:
> Hi Jordan,
>
> Sorry for the empty reply. I clicked on [Send] by accident.
>
> Jordan Crouse wrote:
>>
>> Hmm - we've heard reports of this before, but nothing came of it. I
>> would be interested in a chance to debug it this time.
>>
>> Please try turning off CONFIG_GEODE_MFGPT_TIMER=y and try again.
>
> AFAICS this was already set.
You mean set prior to 2.6.27? I know, but if there is a regression,
that would help narrow it down.
Jordan
Jordan Crouse wrote:
> Also,
> try something in the 2.6.28 family to rule out fixes in the timer
> subsystem.
>
Using 2.6.28-rc7 the problem seems to be gone. There was no complain
about TSC in dmesg, and clock speed is OK. (ntp is off.)
Many thanx
Harri
On Sat, 2008-12-06 at 07:09 +0100, Harald Dunkel wrote:
> john stultz wrote:
> >
> > For both configs, can you run:
> > cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> > and:
> > cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> >
> > Then send back the output?
> >
>
> Sure. For 486:
>
> % cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> pit jiffies
> % cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> pit
>
>
> For Geode (clock is running too fast):
> % cat /sys/devices/system/clocksource/clocksource0/available_clocksource
> jiffies
> % cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> jiffies
>
>
> dmesg says for Geode:
>
> :
> TSC: Unable to calibrate against PIT
> TSC: No reference (HPET/PMTIMER) available
> Marking TSC unstable due to could not calculate TSC khz
Could you send your .config?
It seems the PIT (which is used in 486 build) is being disabled in the
Geode config. However, I thought the Geode's had their own clocksources,
either the SCx200 or the GEODE_MFGPT_TIMER. Maybe one of those needs to
be enabled?
thanks
-john
john stultz wrote:
> On Sat, 2008-12-06 at 07:09 +0100, Harald Dunkel wrote:
>> john stultz wrote:
>>> For both configs, can you run:
>>> cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>>> and:
>>> cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>>>
>>> Then send back the output?
>>>
>> Sure. For 486:
>>
>> % cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>> pit jiffies
>> % cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>> pit
>>
>>
>> For Geode (clock is running too fast):
>> % cat /sys/devices/system/clocksource/clocksource0/available_clocksource
>> jiffies
>> % cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>> jiffies
>>
>>
>> dmesg says for Geode:
>>
>> :
>> TSC: Unable to calibrate against PIT
>> TSC: No reference (HPET/PMTIMER) available
>> Marking TSC unstable due to could not calculate TSC khz
>
> Could you send your .config?
>
> It seems the PIT (which is used in 486 build) is being disabled in the
> Geode config. However, I thought the Geode's had their own clocksources,
> either the SCx200 or the GEODE_MFGPT_TIMER. Maybe one of those needs to
> be enabled?
He sent his original config in his first email - GEODE_MFGPT_TIMER was
enabled. Its not always certain that there are MFGPT timers available
(prior to about the middle of this year, most Geode BIOSes took all the
timers for themselves). But in any case the system should fall back to
PIT automatically, so regardless of more advanced timers. the absence of
a PIT is troubling.
Jordan