Re: 2.6.18 tsc clocksource + ntp = excessive drift; acpi_pm does fine.
[cut] Also does booting w/ "noapic" change the behavior? No, it didn't. It behaves exactly as before. - Alexandre - 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/
Re: 2.6.18 tsc clocksource + ntp = excessive drift; acpi_pm does fine.
[cut] Also does booting w/ noapic change the behavior? No, it didn't. It behaves exactly as before. - Alexandre - 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/
Re: 2.6.18 tsc clocksource + ntp = excessive drift; acpi_pm does fine.
john stultz escreveu: On Tue, 2006-11-28 at 21:46 -0200, Alexandre Pereira Nunes wrote: Hi, with default boot I got tsc clocksource selected on an debian's 2.6.18-3-k7 SMP build (but UP machine). ntp keeps bothering me with this message: frequency error 512 PPM exceeds tolerance 500 PPM Hmmm. Could you send me your dmesg? Also what frequency is your cpu? Sure, attached! You'll notice an "acpi_pm installed" or something at the end, that was at the time I typed the echo acpi_pm >/sys/whatever. My cpu is an athlon xp 2600+, I attached a copy of /proc/cpuinfo for convenience. Also does booting w/ "noapic" change the behavior? I'll test it and let you know. I also read (but didn't try) about some "notsc" option, I assume that's not a good one to try, right? [cut] If I remove ntp's drift file, then do a: echo acpi_pm >/sys/devices/system/clocksource/clocksource0/available_clocksource ; I think you mean "current_clocksource" there... Ooops. Let's just pretend no one else saw that! :-) [cut] Yea, its likely the generic timekeeping changes for i386. Previously (pre-2.6.18) it probably defaulted to the acpi pm timer and was fine. The new code is a bit more aggressive in trying to use the TSC. Just out of curiousity: what about this acpi_pm stuff ... Reading from tsc is probably cheaper than any other "accurate" clock source, but how bad (or good) is acpi_pm? As a short term workaround, you can put "clocksource=acpi_pm" on your grub line and that will force the clocksource at boot. Yeah, I googled around and had put that on grub's config, but didn't reboot. I'll swap that with noapic and reboot, by tomorrow I should have some news. - Alexandre Linux version 2.6.18-3-k7 (Debian 2.6.18-6) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #1 SMP Thu Nov 23 21:37:22 UTC 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000d - 000d6000 (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff8000 (ACPI data) BIOS-e820: 1fff8000 - 2000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 126960 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 AMI ) @ 0x000fa8a0 ACPI: RSDT (v001 AMIINT VIA_K7 0x0010 MSFT 0x0097) @ 0x1fff ACPI: FADT (v001 AMIINT VIA_K7 0x0011 MSFT 0x0097) @ 0x1fff0030 ACPI: MADT (v001 AMIINT VIA_K7 0x0009 MSFT 0x0097) @ 0x1fff00c0 ACPI: DSDT (v001VIA KT266A 0x1000 MSFT 0x010d) @ 0x ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 16 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dec0) Detected 2133.046 MHz processor. Built 1 zonelists. Total pages: 131056 Kernel command line: root=/dev/hda2 ro mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 515356k/524224k available (1556k kernel code, 8332k reserved, 582k data, 196k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4270.91 BogoMIPS (lpj=8541825) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383fbff c1c3fbff CPU: After vendor identify, caps: 0383fbff c1c3fbff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1c3fbff 0420 Intel machine
Re: 2.6.18 tsc clocksource + ntp = excessive drift; acpi_pm does fine.
On Tue, 2006-11-28 at 21:46 -0200, Alexandre Pereira Nunes wrote: > Hi, > > with default boot I got tsc clocksource selected on an debian's > 2.6.18-3-k7 SMP build (but UP machine). ntp keeps bothering me with this > message: > frequency error 512 PPM exceeds tolerance 500 PPM Hmmm. Could you send me your dmesg? Also what frequency is your cpu? Also does booting w/ "noapic" change the behavior? > If I remove ntp's drift file and restart, it goes fine for a while and > then it goes with that behaviour again. > If I remove ntp's drift file, then do a: echo acpi_pm > >/sys/devices/system/clocksource/clocksource0/available_clocksource ; I think you mean "current_clocksource" there... > and then restart ntp, it goes fine "forever". > > Any toughs, something I should look at? > > I'll be glad to give more feedback. > > I don't know if that happened with 2.6.17, but I'm pretty sure that with > 2.6.16 it was fine. Yea, its likely the generic timekeeping changes for i386. Previously (pre-2.6.18) it probably defaulted to the acpi pm timer and was fine. The new code is a bit more aggressive in trying to use the TSC. As a short term workaround, you can put "clocksource=acpi_pm" on your grub line and that will force the clocksource at boot. thanks -john - 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/
2.6.18 tsc clocksource + ntp = excessive drift; acpi_pm does fine.
Hi, with default boot I got tsc clocksource selected on an debian's 2.6.18-3-k7 SMP build (but UP machine). ntp keeps bothering me with this message: frequency error 512 PPM exceeds tolerance 500 PPM If I remove ntp's drift file and restart, it goes fine for a while and then it goes with that behaviour again. If I remove ntp's drift file, then do a: echo acpi_pm >/sys/devices/system/clocksource/clocksource0/available_clocksource ; and then restart ntp, it goes fine "forever". Any toughs, something I should look at? I'll be glad to give more feedback. I don't know if that happened with 2.6.17, but I'm pretty sure that with 2.6.16 it was fine. - Alexandre - 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/
2.6.18 tsc clocksource + ntp = excessive drift; acpi_pm does fine.
Hi, with default boot I got tsc clocksource selected on an debian's 2.6.18-3-k7 SMP build (but UP machine). ntp keeps bothering me with this message: frequency error 512 PPM exceeds tolerance 500 PPM If I remove ntp's drift file and restart, it goes fine for a while and then it goes with that behaviour again. If I remove ntp's drift file, then do a: echo acpi_pm /sys/devices/system/clocksource/clocksource0/available_clocksource ; and then restart ntp, it goes fine forever. Any toughs, something I should look at? I'll be glad to give more feedback. I don't know if that happened with 2.6.17, but I'm pretty sure that with 2.6.16 it was fine. - Alexandre - 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/
Re: 2.6.18 tsc clocksource + ntp = excessive drift; acpi_pm does fine.
On Tue, 2006-11-28 at 21:46 -0200, Alexandre Pereira Nunes wrote: Hi, with default boot I got tsc clocksource selected on an debian's 2.6.18-3-k7 SMP build (but UP machine). ntp keeps bothering me with this message: frequency error 512 PPM exceeds tolerance 500 PPM Hmmm. Could you send me your dmesg? Also what frequency is your cpu? Also does booting w/ noapic change the behavior? If I remove ntp's drift file and restart, it goes fine for a while and then it goes with that behaviour again. If I remove ntp's drift file, then do a: echo acpi_pm /sys/devices/system/clocksource/clocksource0/available_clocksource ; I think you mean current_clocksource there... and then restart ntp, it goes fine forever. Any toughs, something I should look at? I'll be glad to give more feedback. I don't know if that happened with 2.6.17, but I'm pretty sure that with 2.6.16 it was fine. Yea, its likely the generic timekeeping changes for i386. Previously (pre-2.6.18) it probably defaulted to the acpi pm timer and was fine. The new code is a bit more aggressive in trying to use the TSC. As a short term workaround, you can put clocksource=acpi_pm on your grub line and that will force the clocksource at boot. thanks -john - 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/
Re: 2.6.18 tsc clocksource + ntp = excessive drift; acpi_pm does fine.
john stultz escreveu: On Tue, 2006-11-28 at 21:46 -0200, Alexandre Pereira Nunes wrote: Hi, with default boot I got tsc clocksource selected on an debian's 2.6.18-3-k7 SMP build (but UP machine). ntp keeps bothering me with this message: frequency error 512 PPM exceeds tolerance 500 PPM Hmmm. Could you send me your dmesg? Also what frequency is your cpu? Sure, attached! You'll notice an acpi_pm installed or something at the end, that was at the time I typed the echo acpi_pm /sys/whatever. My cpu is an athlon xp 2600+, I attached a copy of /proc/cpuinfo for convenience. Also does booting w/ noapic change the behavior? I'll test it and let you know. I also read (but didn't try) about some notsc option, I assume that's not a good one to try, right? [cut] If I remove ntp's drift file, then do a: echo acpi_pm /sys/devices/system/clocksource/clocksource0/available_clocksource ; I think you mean current_clocksource there... Ooops. Let's just pretend no one else saw that! :-) [cut] Yea, its likely the generic timekeeping changes for i386. Previously (pre-2.6.18) it probably defaulted to the acpi pm timer and was fine. The new code is a bit more aggressive in trying to use the TSC. Just out of curiousity: what about this acpi_pm stuff ... Reading from tsc is probably cheaper than any other accurate clock source, but how bad (or good) is acpi_pm? As a short term workaround, you can put clocksource=acpi_pm on your grub line and that will force the clocksource at boot. Yeah, I googled around and had put that on grub's config, but didn't reboot. I'll swap that with noapic and reboot, by tomorrow I should have some news. - Alexandre Linux version 2.6.18-3-k7 (Debian 2.6.18-6) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #1 SMP Thu Nov 23 21:37:22 UTC 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000d - 000d6000 (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff8000 (ACPI data) BIOS-e820: 1fff8000 - 2000 (ACPI NVS) BIOS-e820: fec0 - fec01000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. On node 0 totalpages: 131056 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 126960 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 AMI ) @ 0x000fa8a0 ACPI: RSDT (v001 AMIINT VIA_K7 0x0010 MSFT 0x0097) @ 0x1fff ACPI: FADT (v001 AMIINT VIA_K7 0x0011 MSFT 0x0097) @ 0x1fff0030 ACPI: MADT (v001 AMIINT VIA_K7 0x0009 MSFT 0x0097) @ 0x1fff00c0 ACPI: DSDT (v001VIA KT266A 0x1000 MSFT 0x010d) @ 0x ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:8 APIC version 16 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dec0) Detected 2133.046 MHz processor. Built 1 zonelists. Total pages: 131056 Kernel command line: root=/dev/hda2 ro mapped APIC to d000 (fee0) mapped IOAPIC to c000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 515356k/524224k available (1556k kernel code, 8332k reserved, 582k data, 196k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 4270.91 BogoMIPS (lpj=8541825) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383fbff c1c3fbff CPU: After vendor identify, caps: 0383fbff c1c3fbff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After all inits, caps: 0383fbff c1c3fbff 0420 Intel machine check architecture
