I have a Foxconn motherboard with Phoenix-Award BIOS and Cedar Mill P4 (Hyperthreading PAE single core) RAID1 system with 11.0 first installed, later 11.2 added, and still later with 11.4 added, now with 3.3.4-1-desktop, giving me three boot choices. 11.4 has been running fine many months, except that /proc/cpuinfo has been reporting my 3.4GHz CPU running at 2400MHz for as long as I can remember, back to when I had a cooling problem and purposely underclocked to keep the temperature down. So today, long after solving the cooling problem, I finally tried to get the CPU speed where it belongs. Eventually I just did a "load optimized defaults" in the BIOS, with a resulting CPU speed within a few MHz of 3400. However, that resulted in the system clock going crazy fast, gaining at least 1.5 minutes every 10 minutes. I Googled and found that Spread Spectrum enabled can cause this, so I went back to the BIOS. I found a way to turn Spread Spectrum off, but that system clock fix brought the CPU speed back down to 2400MHz. The BIOS Spread Spectrum setting has limited access. To reach it, "Fox Intelligent Stepping" needs to be set to "manual", but it is the manual setting that produces 2400MHz CPU speed. I finally figured out that the Spread Spectrum setting appears to remain wherever set while accessible even after restoring to one of the automatic settings that denies access to it. In order to write this, I needed to reboot into the BIOS again to get the right terms. On next boot, I decided to remove CPUFREQ=off from cmdline to see what difference it might make, and the clock error was back. I have no recollection what caused me to include it, but I've had it there at least as long as 11.4 has been installed. Google also said try adding clock=tsc, so next I tried that instead of CPUFREQ=off, also resulting in speedy clock. Google also suggested clock=hpet, which seems to be a fix I'll have to confirm after some sleep. Google said delete /etc/adjtime if the clock runs slightly fast or slow, so I've done that 3-4 times over these boots. I've been using puters for decades, and have never had clock trouble anything like this. I found http://susefaq.sourceforge.net/howto/time.html, but it's 8 years old, not particularly easy to understand, and I have to wonder if kernel evolution has changed things anyway. How common is this kind of clock error? Anyone else here run into this, or know why it ever happens? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata wrote:
I have a Foxconn motherboard with Phoenix-Award BIOS and Cedar Mill P4 (Hyperthreading PAE single core) RAID1 system with 11.0 first installed, later 11.2 added, and still later with 11.4 added, now with 3.3.4-1-desktop, giving me three boot choices. 11.4 has been running fine many months, except that /proc/cpuinfo has been reporting my 3.4GHz CPU running at 2400MHz for as long as I can remember, back to when I had a cooling problem and purposely underclocked to keep the temperature down. So today, long after solving the cooling problem, I finally tried to get the CPU speed where it belongs. Eventually I just did a "load optimized defaults" in the BIOS, with a resulting CPU speed within a few MHz of 3400.
However, that resulted in the system clock going crazy fast, gaining at least 1.5 minutes every 10 minutes. I Googled and found that Spread Spectrum enabled can cause this, so I went back to the BIOS. I found a way to turn Spread Spectrum off, but that system clock fix brought the CPU speed back down to 2400MHz.
Isn't this the clock frequency being automatically reduced when there's no workload? CPUFREQ=off turns of the governor. -- Per Jessen, Zürich (7.8°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/05/12 02:49, Felix Miata wrote:
Google also said try adding clock=tsc, so next I tried that instead of CPUFREQ=off, also resulting in speedy clock. Google also suggested clock=hpet, which seems to be a fix I'll have to confirm after some sleep.
booting with clocksource=hpet should do the trick. I wonder why the kernel is not marking the tsc as unreliable and switching to another clocksource automatically..hrmmm. ps: you hardware is screwed up :-P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012/05/15 02:18 (GMT-0400) Cristian Rodríguez composed:
Felix Miata wrote:
Google also said try adding clock=tsc, so next I tried that instead of CPUFREQ=off, also resulting in speedy clock. Google also suggested clock=hpet, which seems to be a fix I'll have to confirm after some sleep.
booting with clocksource=hpet should do the trick.
Simply clock=hpet is working.
I wonder why the kernel is not marking the tsc as unreliable and switching to another clocksource automatically..hrmmm.
Sounds like a question for kernel people.
ps: you hardware is screwed up :-P
You think? Maybe fallout from a single core CPU pretending to be multi? Stupid/ignorant/broken BIOS? I probably already have the latest BIOS installed. I certainly downloaded the latest long ago, but don't know how to find out the BIOS version from a running Linux, only by rebooting or using DEBUG in a DOS boot. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata wrote:
On 2012/05/15 02:18 (GMT-0400) Cristian Rodríguez composed:
Felix Miata wrote:
Google also said try adding clock=tsc, so next I tried that instead of CPUFREQ=off, also resulting in speedy clock. Google also suggested clock=hpet, which seems to be a fix I'll have to confirm after some sleep.
booting with clocksource=hpet should do the trick.
Simply clock=hpet is working.
I wonder why the kernel is not marking the tsc as unreliable and switching to another clocksource automatically..hrmmm.
Sounds like a question for kernel people.
ps: you hardware is screwed up :-P
You think? Maybe fallout from a single core CPU pretending to be multi? Stupid/ignorant/broken BIOS? I probably already have the latest BIOS installed. I certainly downloaded the latest long ago, but don't know how to find out the BIOS version from a running Linux,
dmidecode. -- Per Jessen, Zürich (13.2°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tuesday, May 15, 2012 10:18:04 AM Per Jessen wrote:
Felix Miata wrote:
On 2012/05/15 02:18 (GMT-0400) Cristian Rodríguez composed:
Felix Miata wrote:
Google also said try adding clock=tsc, so next I tried that instead of CPUFREQ=off, also resulting in speedy clock. Google also suggested clock=hpet, which seems to be a fix I'll have to confirm after some sleep.
booting with clocksource=hpet should do the trick.
Simply clock=hpet is working.
I wonder why the kernel is not marking the tsc as unreliable and switching to another clocksource automatically..hrmmm.
Sounds like a question for kernel people.
ps: you hardware is screwed up :-P
You think? Maybe fallout from a single core CPU pretending to be multi? Stupid/ignorant/broken BIOS? I probably already have the latest BIOS installed. I certainly downloaded the latest long ago, but don't know how to find out the BIOS version from a running Linux,
dmidecode.
Found the solution for finding out the bios version interessting. But with my machine I get: ----- No SMBIOS nor DMI entry point found, sorry. ----- Other solutions? -- Linux User 183145 using KDE4 on a Pentium IV , powered by openSUSE 12.1 (i586) Kernel: 3.3.5-23-desktop KDE Development Platform: 4.8.3 (4.8.3) "release 503") 16:57pm up 17:33, 3 users, load average: 2.63, 1.93, 1.68 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012/05/15 04:18 (GMT-0400) Per Jessen composed:
I probably already have the latest BIOS installed. I certainly downloaded the latest long ago, but don't know how to find out the BIOS version from a running Linux,
dmidecode.
Thanks. It produces a lot of information, but conspicuously absent is the version string. Going by the date though, I never installed it. What is installed is the next to last version. The download page for the latest says for change(s) only "Update CPU Micro code(CPUID=10661)". -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata wrote:
On 2012/05/15 04:18 (GMT-0400) Per Jessen composed:
I probably already have the latest BIOS installed. I certainly downloaded the latest long ago, but don't know how to find out the BIOS version from a running Linux,
dmidecode.
Thanks. It produces a lot of information, but conspicuously absent is the version string.
It'll typically be in the first 20 lines, here are a couple of examples: # dmidecode 2.11 SMBIOS version fixup (2.33 -> 2.3). SMBIOS 2.3 present. 59 structures occupying 1940 bytes. Table at 0x000E0010. Handle 0x0000, DMI type 0, 20 bytes BIOS Information Vendor: IBM Version: 78ET63WW (1.53 ) Release Date: 02/09/2006 Address: 0xE0000 Runtime Size: 128 kB ROM Size: 1024 kB Characteristics: # dmidecode 2.11 SMBIOS 2.3 present. 134 structures occupying 3759 bytes. Table at 0x000EC000. Handle 0x0000, DMI type 0, 20 bytes BIOS Information Vendor: HP Version: P37 Release Date: 06/16/2008 Address: 0xF0000 Runtime Size: 64 kB ROM Size: 4096 kB -- Per Jessen, Zürich (13.7°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012/05/15 16:09 (GMT+0200) Per Jessen composed:
Felix Miata wrote:
Per Jessen composed:
dmidecode.
Thanks. It produces a lot of information, but conspicuously absent is the version string.
It'll typically be in the first 20 lines, here are a couple of examples:
# dmidecode 2.11 ... BIOS Information Vendor: IBM Version: 78ET63WW (1.53 ) Release Date: 02/09/2006 ... BIOS Information Vendor: HP Version: P37 Release Date: 06/16/2008
According to http://www.foxconnsupport.com/download.aspx?models=&category=C000000001&brand=&Series=&chipset=&keywords=p9657ab&sort= (once enough JS links are clicked) the latest version should be 6A2F1P22 and mine should be 6A2F1P21, but this is the dmidecode output: ... BIOS Information Vendor: Phoenix Technologies, LTD Version: 6.00 PG Release Date: 03/20/2008 ... that 6.00 PG is the generic Phoenix version used by the vendor to create the hardware-specific version, same as reported on the title line of BIOS setup, not the vendor's specific BIOS version for the particular release per motherboard. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/15/2012 03:12 AM, Felix Miata wrote:
I wonder why the kernel is not marking the tsc as unreliable and switching to another clocksource automatically..hrmmm.
Sounds like a question for kernel people.
I saw something similar to this on several dell P4/2800->3400 boxes shortly after the release of the 3.0.X kernels. The real time clock on the boxes would drift off into the future by 8 hours in a 24-48 hour period. On these particular boxes, once the time difference exceeded 8 hours, a spontaneous reboot would be triggered. Here is a brief snippet from the logs of what I saw during October of last year: Oct 19 13:15:02 providence crond[955]: time disparity of 301 minutes detected Oct 18 12:42:00 providence crond[958]: time disparity of -479 minutes detected Oct 18 12:32:00 providence crond[1180]: time disparity of -479 minutes detected Oct 18 11:19:01 providence crond[978]: time disparity of -479 minutes detected Oct 18 09:44:01 providence crond[953]: time disparity of -478 minutes detected Oct 12 09:24:01 providence crond[942]: time disparity of -79 minutes detected Oct 7 10:55:59 providence crond[964]: time disparity of 253 minutes detected Oct 5 07:55:57 providence crond[921]: time disparity of 383 minutes detected Oct 3 16:23:01 providence crond[954]: time disparity of 301 minutes detected The problem seemed to be caused by the hwclock being set to LOCALTIME for dual boot. I never found a solution to the problem and ended up just setting the hwclock to UTC. There were no issues when set to UTC. However, there was another user that experienced a 360 min jump with the clock set to UTC. What I did uncover, was that at least for the Arch boxes, LOCALTIME is somewhat deprecated and can produce unpredictable results with new kernels. I don't know that this is related to what you were seeing, but these boxes have all run opensuse and arch for years and I had never experienced this type of clock drift before. I can go back and find out exactly which kernel it was from the mail archive, but the UTC setting eliminated the issue for me, so I haven't bothered to look further. This issue may also have been fixed in updates to the kernel in the past seven months as well. Another surprising thing was this seemed to affect these Dell boxes while other boxes continued to work. So it looked like it was a problem that was part kernel and part bios on those particular machines. Sorry no solutions, but maybe some info here that I'm not seeing might help. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2012/05/15 10:12 (GMT-0500) David C. Rankin composed:
Felix Miata wrote:
I wonder why the kernel is not marking the tsc as unreliable and switching to another clocksource automatically..hrmmm.
Sounds like a question for kernel people.
I saw something similar to this on several dell P4/2800->3400 boxes shortly after the release of the 3.0.X kernels. The real time clock on the boxes would drift off into the future by 8 hours in a 24-48 hour period. ... The problem seemed to be caused by the hwclock being set to LOCALTIME for dual boot. I never found a solution to the problem and ended up just setting the hwclock to UTC. There were no issues when set to UTC. However, there was another user that experienced a 360 min jump with the clock set to UTC.
What I did uncover, was that at least for the Arch boxes, LOCALTIME is somewhat deprecated and can produce unpredictable results with new kernels.
I have a bunch of Dells with P4 CPUs, but the problem here is with a generic motherboard, though made by Foxconn, which was making motherboards for Dell around that time. Your 2800MHz were more likely Prescott, while 3400MHz more likely Cedar Mill. My problem is a 3400MHz Cedar Mill, though I haven't even looked for it on my 2800GHz or faster P4 Dells. The problem machine is the only one in the building not set to local time. Luckily, clock=hpet is an easy enough to live with solution via /etc/sysconfig/bootloader's DEFAULT_APPEND. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2012-05-14 08:49, Felix Miata wrote:
I have a Foxconn motherboard with Phoenix-Award BIOS and Cedar Mill P4 (Hyperthreading PAE single core) RAID1 system with 11.0 first installed, later 11.2 added, and still later with 11.4 added, now with 3.3.4-1-desktop, giving me three boot choices. 11.4 has been running fine many months, except that /proc/cpuinfo has been reporting my 3.4GHz CPU running at 2400MHz for as long as I can remember, back to when I had a cooling problem and purposely underclocked to keep the temperature down. So today, long after solving the cooling problem, I finally tried to get the CPU speed where it belongs. Eventually I just did a "load optimized defaults" in the BIOS, with a resulting CPU speed within a few MHz of 3400.
Notice that the cpu speed should normally be low and speed up when loaded: the system would report the low setting when asked. You can force it to be at the low or high setting permanently if you want. If you display clock speed in a graph, and cause the puter to be loaded, you should see the speed go up.
I've been using puters for decades, and have never had clock trouble anything like this. I found http://susefaq.sourceforge.net/howto/time.html, but it's 8 years old, not particularly easy to understand, and I have to wonder if kernel evolution has changed things anyway.
I wrote that piece. AFAIK, it is basically correct (it does not describe things like hpet or tsc), but what it describe is not related to your problem. I think you should report your clock problem going fast by so many minutes in a bugzilla. - -- Cheers / Saludos, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+yN5YACgkQIvFNjefEBxppvACfdTON5OO8QI8dusfSysmqMSOx N34AnihUrSOz+V3/fDViXdb2R6aklplC =FrYU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (6)
-
Carlos E. R. -
Constant Brouerius van Nidek -
Cristian Rodríguez -
David C. Rankin -
Felix Miata -
Per Jessen