Bugzilla – Bug 113323
System Clock runs at 2x speed
Last modified: 2005-12-30 05:57:38 UTC
System is an Emachine T6212 (MSI mobo, ATI Radeon Xpress 200 chipset).
Can you please provide hwinfo output and a copy of the kernel boot messages (dmeg output)? Thanks!
Created attachment 47848 [details] hwinfo per request
Created attachment 47849 [details] dmesg info
The kernel sets up the ACPI PM timer: time.c: Using 3.579545 MHz PM timer. time.c: Detected 1989.851 MHz processor. time.c: Using PIT/TSC based timekeeping. Maybe this machine has a broken PM timer? Please try booting with nopmtimer
Booted with nopmtimer...clock still running exactly 2X...will attach boot.msg
Created attachment 48071 [details] boot.msg with nopmtimer passed while booting
Alright, next try: what happens if you boot with "notsc"? Andi, do you have any idea what might be wrong here?
Clock still runs at exactly 2X with "notsc"
Created attachment 48238 [details] boot.msg with "notsc" passed
Alright, I'm running out of ideas. Andi, can you help with this, please?
Does the latest kernel from ftp://ftp.suse.com/pub/projects/kernel/kotd/x86_64/HEAD/* still show the problem? It should have a workaround for this ATI chipset issue.
Installed the kotd from 8/30...problem still persists
Created attachment 48390 [details] boot.msg with 8/30 kotd let me know if you want/need more info
Created attachment 48392 [details] boot.msg with 8/30 kotd Sorry...previous was not text
Hmm, the check didn't trigger. Can you add lspci ? The clock is ok when you boot with "no_timer_check", right?
Created attachment 48515 [details] lspci output
clock runs fine with "no_timer_check"
Using "noapictimer" will also bring the clock to normal speed. I've seen this problem in other distributions, including gentoo and ubuntu. My research has shown that this is particularly visible on later generation amd cpus, but I'm not sure if it's only the amd64 or if it also includes sempron. I'm currently using "noapictimer" to keep the timing correct.
The clock running twice as fast as normal is a known bug with the Linux kernel v2.6. See http://bugzilla.kernel.org/show_bug.cgi?id=3927. It seem to be typical with AMD64 + ATI Radeon chipsets. I also have this problem with SuSE 9.3 on an HP Pavillion model 5050.be (this computer has an MSI motherboard, type MS-7093 aka RS480M2 and RX480M2. See http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=639 This problem has also been reported in other places: http://lists.suse.com/archive/suse-amd64/2005-May/0050.html http://www.linuxquestions.org/questions/history/349343 http://nixdoc.net/files/forum/ntopic32168.html There is a patch available (see links above) but I personally don't like to recompile the kernel. I really hope SuSE can fix this for 9.3 and 10.0. A clock at double speed makes the entire OS useless.
I have taken the liberty to increase the severity and priority level of this bug report. 1) The bug is very real and judging by Google result is very common + a solution is available -> increase in priority is necessary 2) Nobody can use an OS for any real work when the clock is going at double speed. -> severity should be set to "Blocker" What us is an OS that runs but cannot be used for any real work?
I do not think this qualifies as a blocker, since using noapictimer or no_timer_check seems to prevent this. IOW there's a known workaround. Moreover the patch posted to the kernel.org bugzilla seems to introduce new problems, and is not ready for inclusion in SL 10.0. Adding aj to the cc list in case he would like to document this in the release notes.
The kernel.org patch is not usable because it breaks other stuff. Need to figure out why the auto detection patch didn't work. I disagree on the blockerness of this too.
AFAIK it should be sufficient to specify either naapictimer or no_timer_check as kernel parameterin GRUB, right? I'm afraid that neither of the two workarounds (noapictimer and no_timer_check) is guaranteed to work. As I have experienced myself, and found others with the same negative experience, these options may cause the computer to lock up during the boot process. Maybe it'll work on some computers, but there is evidence that it is not a surefire workaround. In the end, many users will be left with the choice: - OS boots but clock races at double speed - OS doesn't boot
noapic should always work, doesn't it? Perhaps we just force that on ATI boards for the release.
Once you agreed on the solution, please open a new bug report with component "Release Notes" and tell us what to write.
(In reply to comment #24) > noapic should always work, doesn't it? > noapic also causes the system to hang quite early in the boot process. MSI motherboard, type MS-7093 aka RS480M2 and RX480M2 SuSE 9.3 x86-64 SuSE kernel 2.6.11.4-21.9-default (20050117)
Bart, this bug is about 10.0, not 9.3. Can you test with the current beta kernel?
The problem is still there - lots of reports for mainline. There is one patch that will probably help, but it breaks all other machines.
I have this problem with HP Pavilion a1130n AMD 64 bit SuSe 9.3. I'll try options from this bug thread. noapic definitely causes hang during boot.
on HP Pavilion a1130n AMD 64 bit SuSe 9.3 (ATI chipset) no_timer_check, notsc - do not fix the problem noapic, noapictimer - cause system hang at boot time
Increasing severity to critical again to bring it back onto the radar.
I added a new workaround which will hopefully fix the problem. It didn't make RC2, but you can test the next kotd with this change - patches.arch/x86_64-no-timer-check: (#113323) Update ATI timer bug workaround.
Anyone was able to test it?
(In reply to comment #33) > Anyone was able to test it? > > Andreas, I'm not able to test it because I can't afford to disrupt my production system which is currently running SuSE 9.3, because I'm too busy and because I will be travelling abroad. Also, the following is complete voodoo to me: "kotd" and this reference "- patches.arch/x86_64-no-timer-check: (#113323) Update ATI timer bug workaround". What are we supposed to do with this? Please explain.
kotd is kernel of the day ftp://ftp.suse.com/pub/suse/projects/kernel/kotd/x86_64/HEAD/ (or faster mirror e.g. ftp.gwdg.de) Ok anyone else? Download the kernel rpm from there and rpm -Uvh it and reboot and test if the problem is gone.
Can this kernel also be used with SuSE 9.3? If so, I'm willing to give it a try.
Hmm - why do we have so many people with 9.3 on this 10.0 bug? Please take a look at the version number on top of the page. It'll probably work if you update udev too, but no guarantees.
Andreas: I installed the kotd on RC1...took out the "no_timer_check" parameter from grub... back to 2x clock speed. The only question I have; did I need to install a patch or did the kotd already contain it? Let me know what further info you need...for now, back to "no_timer_check"
This doesn't seem to be in the mirror listed or any of the mirrors I've checked. Is there a mirror confirmed to have the projects directory? I have a system with this problem that I don't mind testing on. One thing to note is I'm using "noapictimer" instead of "no_timer_check". Just a quick note to those using SuSE 9.3 and having this problem...you may want to consider submitting a separate bug report for the 9.3 distro or upgrading to 10 (not recommended for production systems).
Changing back to ASSIGNED per earlier comment #38
I've been doing some testing for another bug and have some information pertaining to this one. As I mentioned, I use the noapictimer flag, which works. In the other bug, there is a suspend to disk problem, and this also appears in 2.6.13.1 vanilla sources. In previous distributions, I've not seen 2.6.13 used, such as with gentoo, who is still using 2.6.12, and some of the problems I'm having with suse 10 don't exist, so I installed vanilla 2.6.12. Suspend to disk and resume works, but it seems when resuming, my noapictimer flag is ignored as the timing seems to revert back to the 2x speed.
Installed kotd kernel-default-2.6.13-20050921081308.x86_64 and took out "no_timer_check"...again, back to 2x clock
Fixed in 10.0 Final
I have this bug bookmarked so I'm gonna go ahead and update it with something I just found from HP concerning this problem. I found a BIOS update from November with this note: "Fixes issue where system time runs twice as fast as it should when the notebook is running a Linux Operating System with Advanced Programmable Interrupt Controller (APIC) enabled." I plan to flash my BIOS and see if there are any additional problems as a result of this fix.