RE: Time jumping on both 4.x and 5.x ...
From: Kris Kennaway [mailto:[EMAIL PROTECTED] > > On Sat, Nov 29, 2003 at 11:32:28AM +0100, Michael Nottebrock wrote: > Content-Description: signed data > > On Saturday 29 November 2003 09:19, Kris Kennaway wrote: > > > > > > Are all affected machines multi-processor? > > > > None. Both are i386 UP (although the 4.9-RELEASE box is > running an SMP-enabled > > kernel). > > I didn't think 4.x SMP kernels could run on a UP machine. They can if the machine has an APIC. ie most P3 and newer boards will run a MP kernel even if only one processor is installed. For me, the bug reproduces on 4.7, and if I set kern.timecounter.method=1, the problem goes away. I've reproduced on both TSC and i8254. --don ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Time jumping on both 4.x and 5.x ...
On Saturday 29 November 2003 11:43, Kris Kennaway wrote: > > I didn't think 4.x SMP kernels could run on a UP machine. It's a pretty decent Pentium4 Mobo, I guess it meets the requirements for an SMP-Board running one CPU. From dmesg: Timecounter "i8254" frequency 1193182 Hz CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz (2421.83-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff real memory = 536805376 (524224K bytes) avail memory = 515989504 (503896K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 IOAPIC #0 intpin 16 -> irq 11 IOAPIC #0 intpin 17 -> irq 10 IOAPIC #0 intpin 18 -> irq 3 IOAPIC #0 intpin 19 -> irq 5 FreeBSD/SMP: Multiprocessor motherboard: 1 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 Warning: Pentium 4 CPU: PSE disabled bktr_mem: memory holder loaded Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 10 entries at 0xc00f7c80 acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
Re: Time jumping on both 4.x and 5.x ...
On Sat, Nov 29, 2003 at 11:32:28AM +0100, Michael Nottebrock wrote: Content-Description: signed data > On Saturday 29 November 2003 09:19, Kris Kennaway wrote: > > > > Are all affected machines multi-processor? > > None. Both are i386 UP (although the 4.9-RELEASE box is running an SMP-enabled > kernel). I didn't think 4.x SMP kernels could run on a UP machine. Kris pgp0.pgp Description: PGP signature
Re: Time jumping on both 4.x and 5.x ...
On Saturday 29 November 2003 09:19, Kris Kennaway wrote: > > Are all affected machines multi-processor? None. Both are i386 UP (although the 4.9-RELEASE box is running an SMP-enabled kernel). -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
Re: Time jumping on both 4.x and 5.x ...
On Sat, Nov 29, 2003 at 07:04:16AM +0100, Michael Nottebrock wrote: Content-Description: signed data > On Saturday 29 November 2003 05:57, Dag-Erling Sm?rgrav wrote: > > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > > > as to ntpd/timed ... don't run either ... run ntpdate twice a day (11:59 > > > and 23:59) > > > > Don't Do That. It will lead to all kinds of trouble that will take > > you ages to figure out. Really, ntpd is so ridiculously easy to set > > up (especially if you already have ntpdate working) that there is no > > reason not to use it. > > FWIW, it can reproduce this on two machines (one 4.9-RELEASE, one 5.1-RELEASE) > which both run ntpd. Takes some 10 minutes on both before the first steps > backwards turn up. > > Unfortunately, both machines aren't very good datapoints because both have > pretty customized kernels and have -Os and -march optimized worlds/kernels... > > Both have kern.timecounter.hardware: ACPI-fast, too. Are all affected machines multi-processor? Kris pgp0.pgp Description: PGP signature
Re: Time jumping on both 4.x and 5.x ...
On Saturday 29 November 2003 05:57, Dag-Erling Smørgrav wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > > as to ntpd/timed ... don't run either ... run ntpdate twice a day (11:59 > > and 23:59) > > Don't Do That. It will lead to all kinds of trouble that will take > you ages to figure out. Really, ntpd is so ridiculously easy to set > up (especially if you already have ntpdate working) that there is no > reason not to use it. FWIW, it can reproduce this on two machines (one 4.9-RELEASE, one 5.1-RELEASE) which both run ntpd. Takes some 10 minutes on both before the first steps backwards turn up. Unfortunately, both machines aren't very good datapoints because both have pretty customized kernels and have -Os and -march optimized worlds/kernels... Both have kern.timecounter.hardware: ACPI-fast, too. -- ,_, | Michael Nottebrock | [EMAIL PROTECTED] (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org pgp0.pgp Description: signature
Re: Time jumping on both 4.x and 5.x ...
On Nov 28, Marc G. Fournier wrote: > > In trying to isolate an issue where the PostgreSQL 'explain analyze' is > showing "odd results" (namely, negative time estimates on queries), Tom > Lane wrote a quick C program to test gettimeofday() (program attached) ... > the results on a 4.9-PRERELEASE kernel of Sep 20 14:16:48 ADT 2003 shows: > > neptune# time ./timetest > out of order tv_sec: 1070068479 99040, prev 1070069174 725235 > out of order tv_usec: 1070068479 99040, prev 1070069174 725235 > out of order tv_sec: 1070069175 19687, prev 1070068479 99040 > out of order tv_usec: 1070069175 19687, prev 1070068479 99040 > out of order tv_sec: 1070068499 99377, prev 1070069194 625573 > out of order tv_usec: 1070068499 99377, prev 1070069194 625573 > out of order tv_sec: 1070069194 808542, prev 1070068499 99377 > ^C1.171u 23.461s 0:24.68 99.7% 5+169k 1+0io 0pf+0w > > One person on the list has tried the same script on a 5.2 kernel, and > reports seeing similar results, but after a longer period of time (~30min) > ... > > In most (all?) cases, the offset appears to be ~+/-695 secs ... Linux ppl > on the list, running the same problem, seem to be able to reproduce the > issue, except they are only finding differences of 1 microsecond, and then > only on older kernels (2.2.x, apparently) ... those running newer Linux > kernels are reporting a clean run ... FreeBSD 5.2 (up, no acpia): I get the errors only when I force heavy load and swapping. - kern.timecounter.hardware: TSC - FreeBSD tube.xx.xx5.2-BETA FreeBSD 5.2-BETA #6: Fri Nov 28 14:20:25 EST 2003 [EMAIL PROTECTED] i386 FreeBSD 4.8 (up): Didn't see the error on a nominally loaded server, I tested for about ten minutes. - kern.timecounter.hardware: i8254 - FreeBSD yy.yy.yy.yy4.8-STABLE FreeBSD 4.8-STABLE #0: Wed Jul 30 13:51:04 EDT 2003 [EMAIL PROTECTED] i386 --Mat -- sig machine boken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Time jumping on both 4.x and 5.x ...
On Sat, Nov 29, 2003 at 12:36:22AM -0400, Marc G. Fournier wrote: > Hardware for the above is a Dual-Xeon, 4Gig of RAM, and about 421 > processes running on it currently ... kernel config is at the bottom, but > I don't think there is anything 'abnormal' about it ... and note that I've > had others be able to reproduce the problem on both 4.x and 5.x systems > ... dmesg output? You need to be VERY specific when reporting bugs that not everyone can reproduce. Kris pgp0.pgp Description: PGP signature
Re: Time jumping on both 4.x and 5.x ...
"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > as to ntpd/timed ... don't run either ... run ntpdate twice a day (11:59 > and 23:59) Don't Do That. It will lead to all kinds of trouble that will take you ages to figure out. Really, ntpd is so ridiculously easy to set up (especially if you already have ntpdate working) that there is no reason not to use it. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Time jumping on both 4.x and 5.x ...
Hello. On Sat, Nov 29, 2003 at 12:36:22AM -0400, Marc G. Fournier wrote: > > What hardware, kernel configuration, etc? Do you have a misconfigured > > ntpd/timed that is manually flapping the time around? > > Hardware for the above is a Dual-Xeon, 4Gig of RAM, and about 421 > processes running on it currently ... kernel config is at the bottom, but > I don't think there is anything 'abnormal' about it ... and note that I've > had others be able to reproduce the problem on both 4.x and 5.x systems > ... > > as to ntpd/timed ... don't run either ... run ntpdate twice a day (11:59 > and 23:59), but that is it as far as playing with the clock is concerned > ... What does `sysctl kern.timecounter' show? Also, does changing kern.timecounter.hardware (TSC, i8254, ACPI-safe, ...) affect the results from your test program? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Time jumping on both 4.x and 5.x ...
On Fri, 28 Nov 2003, Kris Kennaway wrote: > On Fri, Nov 28, 2003 at 09:32:30PM -0400, Marc G. Fournier wrote: > > > > In trying to isolate an issue where the PostgreSQL 'explain analyze' is > > showing "odd results" (namely, negative time estimates on queries), Tom > > Lane wrote a quick C program to test gettimeofday() (program attached) ... > > the results on a 4.9-PRERELEASE kernel of Sep 20 14:16:48 ADT 2003 shows: > > > > neptune# time ./timetest > > out of order tv_sec: 1070068479 99040, prev 1070069174 725235 > > out of order tv_usec: 1070068479 99040, prev 1070069174 725235 > > out of order tv_sec: 1070069175 19687, prev 1070068479 99040 > > out of order tv_usec: 1070069175 19687, prev 1070068479 99040 > > out of order tv_sec: 1070068499 99377, prev 1070069194 625573 > > out of order tv_usec: 1070068499 99377, prev 1070069194 625573 > > out of order tv_sec: 1070069194 808542, prev 1070068499 99377 > > ^C1.171u 23.461s 0:24.68 99.7% 5+169k 1+0io 0pf+0w > > > > One person on the list has tried the same script on a 5.2 kernel, and > > reports seeing similar results, but after a longer period of time (~30min) > > ... > > What hardware, kernel configuration, etc? Do you have a misconfigured > ntpd/timed that is manually flapping the time around? Hardware for the above is a Dual-Xeon, 4Gig of RAM, and about 421 processes running on it currently ... kernel config is at the bottom, but I don't think there is anything 'abnormal' about it ... and note that I've had others be able to reproduce the problem on both 4.x and 5.x systems ... as to ntpd/timed ... don't run either ... run ntpdate twice a day (11:59 and 23:59), but that is it as far as playing with the clock is concerned ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 machine i386 cpu I686_CPU ident kernel maxusers0 makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options NMBCLUSTERS=16384 options VM_KMEM_SIZE="(400*1024*1024)" options VM_KMEM_SIZE_MAX="(400*1024*1024)" options NULLFS #NULL filesystem options UNION #Union filesystem options NFS #Network File System options COMPAT_LINUX options INET#InterNETworking options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH #Improve performance on big directories options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM options SHMMAXPGS=199608 options SHMMAX=(SHMMAXPGS*PAGE_SIZE+1) options SYSVSEM options SEMMNI=4096 options SEMMNS=8192 options SYSVMSG #SYSV-style message queues options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options ICMP_BANDLIM#Rate limit bad replies options KBD_INSTALL_CDEV# install a CDEV entry in /dev options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O device isa device pci device ahd # AHA39320/29320 and onboard AIC79xx devices options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. device scbus # SCSI bus (required) device da # Direct Access (disks) device pass# Passthrough device (direct SCSI access) device ses device atkbdc0 at isa? port IO_KBD device atkbd0 at atkbdc? irq 1 flags 0x1 device psm0at atkbdc? irq 12 device vga0at isa? pseudo-device splash device sc0 at isa? flags 0x100 device npx0at nexus? port IO_NPX irq 13 device em # Intel PRO/1000 adapter Gigabit Ethernet Card ( ``Wiseman'') pseudo-device loop# Network loopback pseudo-device ether # Ethernet support pseudo-device pty 256 # Pseudo-ttys (telnet etc) pseudo-device bpf #Berkeley packet filter options DDB options DDB_UNATTENDED options INCLUDE_CONFIG_FILE # Include this file in kernel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-cu
Re: Time jumping on both 4.x and 5.x ...
On Fri, Nov 28, 2003 at 09:32:30PM -0400, Marc G. Fournier wrote: > > In trying to isolate an issue where the PostgreSQL 'explain analyze' is > showing "odd results" (namely, negative time estimates on queries), Tom > Lane wrote a quick C program to test gettimeofday() (program attached) ... > the results on a 4.9-PRERELEASE kernel of Sep 20 14:16:48 ADT 2003 shows: > > neptune# time ./timetest > out of order tv_sec: 1070068479 99040, prev 1070069174 725235 > out of order tv_usec: 1070068479 99040, prev 1070069174 725235 > out of order tv_sec: 1070069175 19687, prev 1070068479 99040 > out of order tv_usec: 1070069175 19687, prev 1070068479 99040 > out of order tv_sec: 1070068499 99377, prev 1070069194 625573 > out of order tv_usec: 1070068499 99377, prev 1070069194 625573 > out of order tv_sec: 1070069194 808542, prev 1070068499 99377 > ^C1.171u 23.461s 0:24.68 99.7% 5+169k 1+0io 0pf+0w > > One person on the list has tried the same script on a 5.2 kernel, and > reports seeing similar results, but after a longer period of time (~30min) > ... What hardware, kernel configuration, etc? Do you have a misconfigured ntpd/timed that is manually flapping the time around? I've run that test for a few minutes on 4.9 without problems. Kris pgp0.pgp Description: PGP signature
Time jumping on both 4.x and 5.x ...
In trying to isolate an issue where the PostgreSQL 'explain analyze' is showing "odd results" (namely, negative time estimates on queries), Tom Lane wrote a quick C program to test gettimeofday() (program attached) ... the results on a 4.9-PRERELEASE kernel of Sep 20 14:16:48 ADT 2003 shows: neptune# time ./timetest out of order tv_sec: 1070068479 99040, prev 1070069174 725235 out of order tv_usec: 1070068479 99040, prev 1070069174 725235 out of order tv_sec: 1070069175 19687, prev 1070068479 99040 out of order tv_usec: 1070069175 19687, prev 1070068479 99040 out of order tv_sec: 1070068499 99377, prev 1070069194 625573 out of order tv_usec: 1070068499 99377, prev 1070069194 625573 out of order tv_sec: 1070069194 808542, prev 1070068499 99377 ^C1.171u 23.461s 0:24.68 99.7% 5+169k 1+0io 0pf+0w One person on the list has tried the same script on a 5.2 kernel, and reports seeing similar results, but after a longer period of time (~30min) ... In most (all?) cases, the offset appears to be ~+/-695 secs ... Linux ppl on the list, running the same problem, seem to be able to reproduce the issue, except they are only finding differences of 1 microsecond, and then only on older kernels (2.2.x, apparently) ... those running newer Linux kernels are reporting a clean run ... Known problem? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664#include #include int main() { struct timeval prevtime; struct timeval curtime; gettimeofday(&prevtime, NULL); for (;;) { gettimeofday(&curtime, NULL); if (curtime.tv_usec < 0 || curtime.tv_usec >= 100) fprintf(stderr, "bogus tv_usec: %ld %ld, prev %ld %ld\n", (long int) curtime.tv_sec, (long int) curtime.tv_usec, (long int) prevtime.tv_sec, (long int) prevtime.tv_usec); if (curtime.tv_sec < prevtime.tv_sec || curtime.tv_sec > prevtime.tv_sec + 1) fprintf(stderr, "out of order tv_sec: %ld %ld, prev %ld %ld\n", (long int) curtime.tv_sec, (long int) curtime.tv_usec, (long int) prevtime.tv_sec, (long int) prevtime.tv_usec); if (curtime.tv_usec < prevtime.tv_usec && curtime.tv_sec != prevtime.tv_sec + 1) fprintf(stderr, "out of order tv_usec: %ld %ld, prev %ld %ld\n", (long int) curtime.tv_sec, (long int) curtime.tv_usec, (long int) prevtime.tv_sec, (long int) prevtime.tv_usec); prevtime = curtime; } return 0; } ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"