|
|
在我新装的64位Gentoo系统中，现实时间大概0.5秒Linux系统中的时钟就要走1秒，搞得我emerge时常常有警告某某文件的修改时间是在未来。
我的CPU是AMD X2 3800+，启动的时候可以看到两只企鹅，难道是每个CPU核心1秒钟加1，所以系统的时间就相当于实际一秒钟走了2秒？
系统：SMP x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
2.6.15-gentoo-r3
ATI 芯片组
凑合解决办法：
BIOS里Power管理项目里关掉了APIC，grub.conf中给内核加上了noapic参数。
以下转贴解决方法：
http://forums.gentoo.org/viewtop ... ght-clock+fast.html
Synopsis
Your new ACPI-only laptop's clock rate is exactly or almost exactly double that of realtime. This differs from possible clock skew issues as it is not easily correctible using NTP.
Effected Systems
The following systems are known to be effected by this problem:
* HP Pavilion zv6000-Series Notebook Computers
* Compaq Presario r4000-Series Notebook Computers
There is a possibility of future HP / Compaq laptops and other computers using a combination of ATI chipsets and AMD Athlon™ 64 processors also having this issue.
Defining the Problem / Symptoms
Symptoms of this problem include, and may not be limited to:
* Running 'while true; do sleep 1; date; done' displays a second passing every half-second.
* Animations in Xorg (KDE, Gnome, whatever) run exceptionally fast.
* An insane keyboard repeat rate that may, in fact, make it nearly impossible to type anything.
* Elevated system utilization (as much as 50% constant useage reported by some applications).
* Warnings along the lines of 'clock skew detected: build may be incomplete' when compiling the kernel or applications from source.
* Cache results will be quirky, as eventually the clock is so far in the future that no server in the world can report times in your future. Similarily, rsync results will vary.
* Worst case, you are excessively late to meetings; or, best case, excessively early.
The Solution (32-Bit)
The following have been known to work, but are currently untested by myself on the latest kernels:
* Apply the following patch (posted by Christopher Allen Wing) and add the "timerhack" option to your kernel command line. (In GRUB add it to the end of the "kernel=" line, in LILO add it to the "append=" line.) Malone pointed me to the original thread on LKML. Thanks, malone!
Code:
- --- linux-2.6.11.6/arch/x86_64/kernel/io_apic.c.orig 2005-03-25 22:28:21.000000000 -0500
- +++ linux-2.6.11.6/arch/x86_64/kernel/io_apic.c 2005-04-06 17:56:46.486511088 -0400
- @@ -1564,6 +1564,8 @@
- * is so screwy. Thanks to Brian Perkins for testing/hacking this beast
- * fanatically on his truly buggy board.
- */
- +static int timer_hack = 0;
- +
- static inline void check_timer(void)
- {
- int pin1, pin2;
- @@ -1592,6 +1594,10 @@
- apic_printk(APIC_VERBOSE,KERN_INFO "..TIMER: vector=0x%02X pin1=%d pin2=%d\n", vector, pin1, pin2);
- + if (timer_hack) {
- + /* for some reason this stops duplicate timer IRQ? */
- + clear_IO_APIC_pin(0, pin1);
- + } else {
- if (pin1 != -1) {
- /*
- * Ok, does IRQ0 through the IOAPIC work?
- @@ -1633,6 +1639,7 @@
- clear_IO_APIC_pin(0, pin2);
- }
- printk(" failed.\n");
- + }
- if (nmi_watchdog) {
- printk(KERN_WARNING "timer doesn't work through the IO-APIC - disabling NMI Watchdog!\n");
- @@ -1669,6 +1676,14 @@
- panic("IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter\n");
- }
- +static int __init timerhack(char *str)
- +{
- + timer_hack = 1;
- + return 1;
- +}
- +__setup("timerhack", timerhack);
- +
- +
- /*
- *
- * IRQ's that are handled by the PIC in the MPS IOAPIC case.
* Or, apply this second patch, also posted by Christopher. It is a little less hackish than the first, but accomplishes the same thing.
Code:
- --- arch/x86_64/kernel/io_apic.c.orig 2005-03-25 22:28:21.000000000 -0500
- +++ arch/x86_64/kernel/io_apic.c 2005-04-07 13:13:58.813193024 -0400
- @@ -1564,6 +1564,8 @@
- * is so screwy. Thanks to Brian Perkins for testing/hacking this beast
- * fanatically on his truly buggy board.
- */
- +static int timer_hack = 0;
- +
- static inline void check_timer(void)
- {
- int pin1, pin2;
- @@ -1597,7 +1599,7 @@
- * Ok, does IRQ0 through the IOAPIC work?
- */
- unmask_IO_APIC_irq(0);
- - if (timer_irq_works()) {
- + if ((!timer_hack) && timer_irq_works()) {
- nmi_watchdog_default();
- if (nmi_watchdog == NMI_IO_APIC) {
- disable_8259A_irq(0);
- @@ -1669,6 +1671,14 @@
- panic("IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter\n");
- }
- +static int __init timerhack(char *str)
- +{
- + timer_hack = 1;
- + return 1;
- +}
- +__setup("timerhack", timerhack);
- +
- +
- /*
- *
- * IRQ's that are handled by the PIC in the MPS IOAPIC case.
The Solution (64-Bit)
There are many proposed solutions. A few of the more successful ones include:
1. Upgrading to the latest 2.6 kernel and keeping the support applications (like pci-utils) updated. Remember - new features may have been added such as new drivers, an updated PCI-ID listing, etc.
2. Trying various combinations of the HPET, HPET_TIMER, HPET_EMULATE_RTC, X86_MCE, X86_PM_TIMER, and RTC options in the kernel.
3. Passing various kernel options at boot. These include:
* no_timer_check
* pci=biosirq
* pci=noacpi
* pci=irqroute
* clock=pmtmr
* notsc
* noapic
* noapictimer (previousally used by 13Homer)
Passing the no_timer_check option was all that was required to solve it for me! |
|
IP卡
狗仔卡
发表于 2006-2-6 17:47:48
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
楼主