Re: ntpd dies on startup if using -s option
Jumping the clock doesn't play well with rtsol. If it jumps too far, ipv6 timers expire, you lose your rtsol'd address/route, and it takes a little time to reacquire them. It might work to use rdate_flags and set the clock before ntpd starts, but this is a bit racy. On 2009-06-17, Stefan Unterweger ste...@rg-me.it wrote: * Paul de Weerd on Wed, Jun 17, 2009 at 11:34:38AM +0200: Just em0, which is connected to the LAN and gets all of its configuration via DHCP and rtsol. Is (one of) your ntp server(s) v6 only ? Do you have rtsol in your /etc/hostname.em0 ? Yes and yes. Do you get a lease immediately on boot or could there be some delay ? It sounds like you don't have proper connectivity yet when ntpd tries to start (either v4 or v6 (or both)). Verify this by putting something like 'ifconfig -a /tmp/ifc.out' in /etc/rc.local. As far as I glanced, the rtsol lease should already be present when ntpd tries to start, or at least the machine already knows where to reach the v6 gateway. But this is from memory; I will test it as soon as I get back to the machine in question. If I *don't* go with rtsol but e.g. let aiccu set up a gif-tunnel, ntpd get's up cleanly, sees that there's no way to reach the v6-servers (yet) (since aiccu would be invoked from rc.local, thus way after ntpd), syncs to the v4 ones, and some time later (successfully) starts connecting to the v6 ones. s//un
Re: ntpd dies on startup if using -s option
Hi! On Thu, Jun 18, 2009 at 12:17:12PM +, Stuart Henderson wrote: Jumping the clock doesn't play well with rtsol. If it jumps too far, ipv6 timers expire, you lose your rtsol'd address/route, and it takes a little time to reacquire them. Shouldn't rtsold use something like clock_gettime and CLOCK_MONOTONIC then? (Or if it's about kernel parts, the kernel equivalent thereof, i.e. monotime, if I remember things correctly w/o looking at the source.) Kind regards, Hannah.
ntpd dies on startup if using -s option
Hello! I have noticed a rather curious behaviour of ntpd on startup. I recently started setting the '-s' option to ntpd in rc.conf.local on my machines. The sloppy hardware clocks on those machines combined with the lack of any kind of USV often leads to several minutes of clock skey on reboot (they are supposed to run 24/7, so unless I do an upgrade every reboot is unclean). Some services depend on accurate time synchronization, so they won't come up again after reboot. Thus the '-s'. As far as I understood from the manpage, it's supposed to set the clock immediately on invocation and store it back into the hardware clock, and according to my tests it just does that. Unless it is supposed to to that on boot, read: when invoked from rc(8). Watching the console, I see that ntpd fails to stay up and throws up on my feet (without having set the clock, of course). /var/log/daemon has the following to say: | Jun 17 07:38:26 knoedel ntpd[17639]: ntp engine ready | Jun 17 07:38:26 knoedel ntpd[17639]: fatal: recvfrom: Protocol not available | Jun 17 07:38:26 knoedel ntpd[27003]: dispatch_imsg in main: pipe closed (I did set a bogus time into the hardware clock on purpose to see if this would work.) If I issue 'ntpd -s' after boot has completed, everything runs fine; same thing if I run ntpd from rc.local, but somehow this feels unclean. intro(2) says the following about the error message: 42 ENOPROTOOPT Protocol not available. A bad option or level was specified in a getsockopt(2) or setsockopt(2) call. But I am not enough of a programmer to make sense of this description. Is this some kind of bug, or am I simply trying to do something that is not supposed to be done this way? Thanks for any advice, s//un
Re: ntpd dies on startup if using -s option
Sorry, I have been too fast to post: The machine in question I have been testing this with is running 4.5 release. Running `ntpd -s` from rc.local does *not* work (I must have misread the log the first time, now it defitinely does not work) -- I actually have to wait until rc is done and I can login manually until it works. s//un
Re: ntpd dies on startup if using -s option
Stefan Unterweger wrote: Hello! I have noticed a rather curious behaviour of ntpd on startup. I recently started setting the '-s' option to ntpd in rc.conf.local on my machines. The sloppy hardware clocks on those machines combined with the lack of any kind of USV often leads to several minutes of clock skey on reboot (they are supposed to run 24/7, so unless I do an upgrade every reboot is unclean). Some services depend on accurate time synchronization, so they won't come up again after reboot. Thus the '-s'. As far as I understood from the manpage, it's supposed to set the clock immediately on invocation and store it back into the hardware clock, and according to my tests it just does that. Unless it is supposed to to that on boot, read: when invoked from rc(8). Watching the console, I see that ntpd fails to stay up and throws up on my feet (without having set the clock, of course). /var/log/daemon has the following to say: | Jun 17 07:38:26 knoedel ntpd[17639]: ntp engine ready | Jun 17 07:38:26 knoedel ntpd[17639]: fatal: recvfrom: Protocol not available | Jun 17 07:38:26 knoedel ntpd[27003]: dispatch_imsg in main: pipe closed (I did set a bogus time into the hardware clock on purpose to see if this would work.) If I issue 'ntpd -s' after boot has completed, everything runs fine; same thing if I run ntpd from rc.local, but somehow this feels unclean. intro(2) says the following about the error message: 42 ENOPROTOOPT Protocol not available. A bad option or level was specified in a getsockopt(2) or setsockopt(2) call. But I am not enough of a programmer to make sense of this description. Is this some kind of bug, or am I simply trying to do something that is not supposed to be done this way? What is your network setup? dmesg too. any special kernel config? /Alexander
Re: ntpd dies on startup if using -s option
* Alexander Hall on Wed, Jun 17, 2009 at 10:40:58AM +0200: What is your network setup? The network setup is rather simple: | lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33160 | priority: 0 | groups: lo | inet 127.0.0.1 netmask 0xff00 | inet6 ::1 prefixlen 128 | inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 | em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 | lladdr 00:0f:fe:de:59:49 | priority: 0 | groups: egress | media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) | status: active | inet6 fe80::20f:feff:fede:5949%em0 prefixlen 64 scopeid 0x1 | inet 10.13.130.58 netmask 0xff00 broadcast 10.13.130.255 | inet6 2001:1418:16b:0:20f:feff:fede:5949 prefixlen 64 autoconf pltime 604684 vltime 2591884 | enc0: flags=0 mtu 1536 | priority: 0 Just em0, which is connected to the LAN and gets all of its configuration via DHCP and rtsol. any special kernel config? I have activated RAIDframe; other than that, the kernel is pure (see config file below). | include arch/amd64/conf/GENERIC.MP | pseudo-device raid | option RAID_AUTOCONFIG The system I have been testing this with is almost bare; other than vim and zsh there is next to nothing on it. dmesg too. | OpenBSD 4.5 (GENERIC.RAID) #0: Mon May 18 10:55:01 CEST 2009 | r...@kriegspire.rg-me.schule.suedtirol.it:/usr/src/sys/arch/amd64/compile/GENERIC.RAID | real mem = 2098917376 (2001MB) | avail mem = 2025533440 (1931MB) | mainbus0 at root | bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xea0c0 (77 entries) | bios0: vendor Hewlett-Packard version 786F1 v01.26 date 07/31/2008 | bios0: Hewlett-Packard HP Compaq dc7800p Convertible Minitower | acpi0 at bios0: rev 0 | acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET DMAR | acpi0: wakeup devices COM1(S4) COM2(S4) PCI0(S4) PEG1(S4) PEG2(S4) IGBE(S4) PCX1(S4) PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) EUS1(S3) EUS2(S3) PBTN(S4) | acpitimer0 at acpi0: 3579545 Hz, 24 bits | acpimadt0 at acpi0 addr 0xfee0: PC-AT compat | cpu0 at mainbus0: apid 0 (boot processor) | cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.89 MHz | cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR,NXE,LONG | cpu0: 6MB 64b/line 16-way L2 cache | cpu0: apic clock running at 332MHz | cpu1 at mainbus0: apid 1 (application processor) | cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.50 MHz | cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR,NXE,LONG | cpu1: 6MB 64b/line 16-way L2 cache | ioapic0 at mainbus0 apid 1 pa 0xfec0, version 20, 24 pins | ioapic0: misconfigured as apic 0, remapped to apid 1 | acpihpet0 at acpi0: 14318179 Hz | acpiprt0 at acpi0: bus 0 (PCI0) | acpiprt1 at acpi0: bus -1 (PEG1) | acpiprt2 at acpi0: bus -1 (PEG2) | acpiprt3 at acpi0: bus 32 (PCX1) | acpiprt4 at acpi0: bus 48 (PCX2) | acpiprt5 at acpi0: bus -1 (PCX5) | acpiprt6 at acpi0: bus -1 (PCX6) | acpiprt7 at acpi0: bus 7 (HUB_) | acpicpu0 at acpi0: C2 | acpicpu1 at acpi0: C2 | acpibtn0 at acpi0: PBTN | cpu0: unknown Enhanced SpeedStep CPU, msr 0x061a092206000922 | cpu0: using only highest and lowest power states | cpu0: Enhanced SpeedStep 3000 MHz (1244 mV): speeds: 3000, 2000 MHz | pci0 at mainbus0 bus 0: configuration mode 1 | pchb0 at pci0 dev 0 function 0 Intel 82Q35 Host rev 0x02 | vga1 at pci0 dev 2 function 0 Intel 82Q35 Video rev 0x02 | wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) | wsdisplay0: screen 1-5 added (80x25, vt100 emulation) | intagp0 at vga1 | agp0 at intagp0: aperture at 0xe000, size 0x1000 | inteldrm0 at vga1: apic 1 int 16 (irq 5) | drm0 at inteldrm0 | Intel 82Q35 Video rev 0x02 at pci0 dev 2 function 1 not configured | Intel 82Q35 HECI rev 0x02 at pci0 dev 3 function 0 not configured | pciide0 at pci0 dev 3 function 2 Intel 82Q35 PT IDER rev 0x02: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI | pciide0: using apic 1 int 18 (irq 10) for native-PCI interrupt | pciide0: channel 0 ignored (not responding; disabled or no drives?) | pciide0: channel 1 ignored (not responding; disabled or no drives?) | Intel 82Q35 KT rev 0x02 at pci0 dev 3 function 3 not configured | em0 at pci0 dev 25 function 0 Intel ICH9 IGP AMT rev 0x02: apic 1 int 19 (irq 5), address 00:0f:fe:de:59:49 | uhci0 at pci0 dev 26 function 0 Intel 82801I USB rev 0x02: apic 1 int 20 (irq 10) | uhci1 at pci0 dev 26 function 1 Intel 82801I USB rev 0x02: apic 1 int 21 (irq 11) | ehci0 at pci0 dev 26 function 7 Intel 82801I USB rev 0x02: apic 1 int 22 (irq 5) | usb0 at ehci0: USB revision 2.0 | uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 | azalia0 at pci0 dev 27 function 0
Re: ntpd dies on startup if using -s option
Stefan Unterweger wrote: * Alexander Hall on Wed, Jun 17, 2009 at 10:40:58AM +0200: What is your network setup? The network setup is rather simple: | lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33160 | priority: 0 | groups: lo | inet 127.0.0.1 netmask 0xff00 | inet6 ::1 prefixlen 128 | inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 | em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 | lladdr 00:0f:fe:de:59:49 | priority: 0 | groups: egress | media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) | status: active | inet6 fe80::20f:feff:fede:5949%em0 prefixlen 64 scopeid 0x1 | inet 10.13.130.58 netmask 0xff00 broadcast 10.13.130.255 | inet6 2001:1418:16b:0:20f:feff:fede:5949 prefixlen 64 autoconf pltime 604684 vltime 2591884 | enc0: flags=0 mtu 1536 | priority: 0 Just em0, which is connected to the LAN and gets all of its configuration via DHCP and rtsol. Ah. Sure sounds like this could be an IPv6 issue. That's not at all my turf though, so let's hope someone more knowledgeable in that area chimes in. any special kernel config? I have activated RAIDframe; other than that, the kernel is pure (see config file below). | include arch/amd64/conf/GENERIC.MP | pseudo-device raid | option RAID_AUTOCONFIG Not that it should matter here, but just for the record; Don't claim that your system is running 4.5-release when it clearly is not since you modified the kernel. /Alexander The system I have been testing this with is almost bare; other than vim and zsh there is next to nothing on it. dmesg too. | OpenBSD 4.5 (GENERIC.RAID) #0: Mon May 18 10:55:01 CEST 2009 | r...@kriegspire.rg-me.schule.suedtirol.it:/usr/src/sys/arch/amd64/compile/GENERIC.RAID | real mem = 2098917376 (2001MB) | avail mem = 2025533440 (1931MB) | mainbus0 at root | bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xea0c0 (77 entries) | bios0: vendor Hewlett-Packard version 786F1 v01.26 date 07/31/2008 | bios0: Hewlett-Packard HP Compaq dc7800p Convertible Minitower | acpi0 at bios0: rev 0 | acpi0: tables DSDT FACP APIC ASF! MCFG TCPA SLIC HPET DMAR | acpi0: wakeup devices COM1(S4) COM2(S4) PCI0(S4) PEG1(S4) PEG2(S4) IGBE(S4) PCX1(S4) PCX2(S4) PCX5(S4) PCX6(S4) HUB_(S4) USB1(S3) USB2(S3) USB3(S3) USB4(S3) USB5(S3) USB6(S3) EUS1(S3) EUS2(S3) PBTN(S4) | acpitimer0 at acpi0: 3579545 Hz, 24 bits | acpimadt0 at acpi0 addr 0xfee0: PC-AT compat | cpu0 at mainbus0: apid 0 (boot processor) | cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.89 MHz | cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR,NXE,LONG | cpu0: 6MB 64b/line 16-way L2 cache | cpu0: apic clock running at 332MHz | cpu1 at mainbus0: apid 1 (application processor) | cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz, 2992.50 MHz | cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR,NXE,LONG | cpu1: 6MB 64b/line 16-way L2 cache | ioapic0 at mainbus0 apid 1 pa 0xfec0, version 20, 24 pins | ioapic0: misconfigured as apic 0, remapped to apid 1 | acpihpet0 at acpi0: 14318179 Hz | acpiprt0 at acpi0: bus 0 (PCI0) | acpiprt1 at acpi0: bus -1 (PEG1) | acpiprt2 at acpi0: bus -1 (PEG2) | acpiprt3 at acpi0: bus 32 (PCX1) | acpiprt4 at acpi0: bus 48 (PCX2) | acpiprt5 at acpi0: bus -1 (PCX5) | acpiprt6 at acpi0: bus -1 (PCX6) | acpiprt7 at acpi0: bus 7 (HUB_) | acpicpu0 at acpi0: C2 | acpicpu1 at acpi0: C2 | acpibtn0 at acpi0: PBTN | cpu0: unknown Enhanced SpeedStep CPU, msr 0x061a092206000922 | cpu0: using only highest and lowest power states | cpu0: Enhanced SpeedStep 3000 MHz (1244 mV): speeds: 3000, 2000 MHz | pci0 at mainbus0 bus 0: configuration mode 1 | pchb0 at pci0 dev 0 function 0 Intel 82Q35 Host rev 0x02 | vga1 at pci0 dev 2 function 0 Intel 82Q35 Video rev 0x02 | wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) | wsdisplay0: screen 1-5 added (80x25, vt100 emulation) | intagp0 at vga1 | agp0 at intagp0: aperture at 0xe000, size 0x1000 | inteldrm0 at vga1: apic 1 int 16 (irq 5) | drm0 at inteldrm0 | Intel 82Q35 Video rev 0x02 at pci0 dev 2 function 1 not configured | Intel 82Q35 HECI rev 0x02 at pci0 dev 3 function 0 not configured | pciide0 at pci0 dev 3 function 2 Intel 82Q35 PT IDER rev 0x02: DMA (unsupported), channel 0 wired to native-PCI, channel 1 wired to native-PCI | pciide0: using apic 1 int 18 (irq 10) for native-PCI interrupt | pciide0: channel 0 ignored (not responding; disabled or no drives?) | pciide0: channel 1 ignored (not responding; disabled or no drives?) | Intel 82Q35 KT rev 0x02 at pci0 dev 3 function 3 not configured | em0 at pci0 dev 25 function 0 Intel ICH9
Re: ntpd dies on startup if using -s option
* Alexander Hall on Wed, Jun 17, 2009 at 11:20:25AM +0200: Just em0, which is connected to the LAN and gets all of its configuration via DHCP and rtsol. Ah. Sure sounds like this could be an IPv6 issue. That's not at all my turf though, so let's hope someone more knowledgeable in that area chimes in. Now that you mentioned it, it does indeed seem like an IPv6 issue. I have set up ntpd to sync via pool.ntp.org and ntp.eu.sixxs.org. If I comment out the latter entry (or if there is no IPv6 connectivity at boot), the problem is no more... Not that it should matter here, but just for the record; Don't claim that your system is running 4.5-release when it clearly is not since you modified the kernel. Sorry, you're of course right. What I tried to say was that I am using the system as from the CDs, with the said customized kernel. s//un
Re: ntpd dies on startup if using -s option
On Wed, Jun 17, 2009 at 11:03:32AM +0200, Stefan Unterweger wrote: | * Alexander Hall on Wed, Jun 17, 2009 at 10:40:58AM +0200: | What is your network setup? | | The network setup is rather simple: | | lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33160 | | priority: 0 | | groups: lo | | inet 127.0.0.1 netmask 0xff00 | | inet6 ::1 prefixlen 128 | | inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 | | em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 | | lladdr 00:0f:fe:de:59:49 | | priority: 0 | | groups: egress | | media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause) | | status: active | | inet6 fe80::20f:feff:fede:5949%em0 prefixlen 64 scopeid 0x1 | | inet 10.13.130.58 netmask 0xff00 broadcast 10.13.130.255 | | inet6 2001:1418:16b:0:20f:feff:fede:5949 prefixlen 64 autoconf pltime 604684 vltime 2591884 | | enc0: flags=0 mtu 1536 | | priority: 0 | | Just em0, which is connected to the LAN and gets all of its configuration via DHCP and rtsol. Is (one of) your ntp server(s) v6 only ? Do you have rtsol in your /etc/hostname.em0 ? Do you get a lease immediately on boot or could there be some delay ? It sounds like you don't have proper connectivity yet when ntpd tries to start (either v4 or v6 (or both)). Verify this by putting something like 'ifconfig -a /tmp/ifc.out' in /etc/rc.local. Paul 'WEiRD' de Weerd -- [++-]+++.+++[---].+++[+ +++-].++[-]+.--.[-] http://www.weirdnet.nl/
Re: ntpd dies on startup if using -s option
2009/6/17 Stefan Unterweger stefan+open...@rg-me.it: Hello! I have noticed a rather curious behaviour of ntpd on startup. I recently started setting the '-s' option to ntpd in rc.conf.local on my machines. The sloppy hardware clocks on those machines combined with the lack of any kind of USV... *ahem* Wenn ist das Nunstruck git und Slotermeyer? Ja!... Beiherhund das Oder die Flipperwaldt gersput! regards, --ropers
ntpd dies on startup if using -s option
I'm actually having this issue as well. I'm running current on an old Netra T105 and at boot the date isn't updated when running ntpd with the -s option. It won't even do it from the commandline I think because the skew it so bad (the bottom of the dmesg outlines it clearly). I had to set the date by hand to get it close and then startup ntpd to get it run with the -s option. I'm not running ipv6 and my ntp server is my OBSD firewall. When I tried to run ntpd with -s I get the following errors: Nov 25 09:34:10 blade ntpd[8306]: recvmsg control format 192.168.250.1: No such file or directory Nov 25 09:34:38 blade ntpd[29786]: dispatch_imsg in main: pipe closed I guess the real question is do I need to change the damn battery or is there an issue with ntpd with a large skew ? Thanks in advance. Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address(state) udp0 0 192.168.150.222.26027 192.168.250.1.123 OpenBSD 4.5-current (GENERIC) #0: Sun Jun 14 02:35:19 MDT 2009 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/GENERIC real mem = 536870912 (512MB) avail mem = 507363328 (483MB) mainbus0 at root: Netra t1 (UltraSPARC-IIi 440MHz) cpu0 at mainbus0: SUNW,UltraSPARC-IIi (rev 9.1) @ 440.011 MHz cpu0: physical 16K instruction (32 b/l), 16K data (32 b/l), 2048K external (64 b/l) psycho0 at mainbus0 addr 0xfffc: SUNW,sabre, impl 0, version 0, ign 7c0 psycho0: bus range 0-3, PCI bus 0 psycho0: dvma map c000-dfff pci0 at psycho0 ppb0 at pci0 dev 1 function 1 Sun Simba PCI-PCI rev 0x13 pci1 at ppb0 bus 1 ebus0 at pci1 dev 1 function 0 Sun PCIO EBus2 rev 0x01 auxio0 at ebus0 addr 726000-726003, 728000-728003, 72a000-72a003, 72c000-72c003, 72f000-72f003 power0 at ebus0 addr 724000-724003 ivec 0x25 SUNW,pll at ebus0 addr 504000-504002 not configured com0 at ebus0 addr 3803f8-3803ff ivec 0x1c: ns16550a, 16 byte fifo com0: console com1 at ebus0 addr 3602f8-3602ff ivec 0x14: ns16550a, 16 byte fifo lpt0 at ebus0 addr 340278-340287, 30015c-30015d, 70-7f ivec 0x22: polled clock1 at ebus0 addr 0-1fff: mk48t59 flashprom at ebus0 addr 0-f not configured watchdog at ebus0 addr 20-20003f ivec 0x4 not configured display7seg at ebus0 addr 200040-200040 not configured beeper0 at ebus0 addr 722000-722003 flashprom at ebus0 addr 40-5f not configured flashprom at ebus0 addr 80-9f not configured pcfiic0 at ebus0 addr 60-63 ivec 0x28 iic0 at pcfiic0 pcfadc0 at iic0 addr 0x4f i2cpcf,8574a at iic0 addr 0x38 not configured i2cpcf,8574a at iic0 addr 0x39 not configured pcfiic1 at ebus0 addr 10-13 ivec 0x1b iic1 at pcfiic1 SUNW,lom at ebus0 addr 40-400063 not configured hme0 at pci1 dev 1 function 1 Sun HME rev 0x01: ivec 0x7e1, address 08:00:20:c1:e5:66 luphy0 at hme0 phy 0: LU6612 10/100 PHY, rev. 1 siop0 at pci1 dev 2 function 0 Symbios Logic 53c875 rev 0x03: ivec 0x7e0, using 4K of on-board RAM scsibus0 at siop0: 16 targets, initiator 7 sd0 at scsibus0 targ 0 lun 0: FUJITSU, MAG3091L SUN9.0G, SCSI2 0/direct fixed sd0: 8637MB, 512 bytes/sec, 17689267 sec total sd1 at scsibus0 targ 1 lun 0: FUJITSU, MAG3091L SUN9.0G, SCSI2 0/direct fixed sd1: 8637MB, 512 bytes/sec, 17689267 sec total hme1 at pci1 dev 3 function 1 Sun HME rev 0x01: ivec 0x7da, address 08:00:20:c1:e5:67 luphy1 at hme1 phy 0: LU6612 10/100 PHY, rev. 1 ppb1 at pci0 dev 1 function 0 Sun Simba PCI-PCI rev 0x13 pci2 at ppb1 bus 2 ppb2 at pci2 dev 1 function 0 DEC 21150 PCI-PCI rev 0x04 pci3 at ppb2 bus 3 pciide0 at pci3 dev 14 function 0 CMD Technology PCI0646 rev 0x03: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using ivec 0x7c2 for native-PCI interrupt pciide0: channel 0 disabled (no drives) atapiscsi0 at pciide0 channel 1 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: TOSHIBA, CD-ROM XM-1902B, 1114 ATAPI 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, DMA mode 2 softraid0 at root siop0: target 0 now using tagged 16 bit 20.0 MHz 16 REQ/ACK offset xfers siop0: target 1 now using tagged 16 bit 20.0 MHz 16 REQ/ACK offset xfers bootpath: /p...@1f,0/p...@1,1/s...@2,0/d...@0,0 root on sd0a swap on sd0b dump on sd0b WARNING: preposterous time in file system WARNING: clock lost 21767 days -- CHECK AND RESET THE DATE!
Re: ntpd dies on startup if using -s option
* Allie Daneman d...@drainfade.com [2009-06-17 21:24]: I'm actually having this issue as well. I'm running current on an old Netra T105 and at boot the date isn't updated when running ntpd with the -s option. It won't even do it from the commandline I think because the skew it so bad (the bottom of the dmesg outlines it clearly). I had to set the date by hand to get it close and then startup ntpd to get it run with the -s option. I'm not running ipv6 and my ntp server is my OBSD firewall. When I tried to run ntpd with -s I get the following errors: Nov 25 09:34:10 blade ntpd[8306]: recvmsg control format 192.168.250.1: No such file or directory this is weird. this means the message received has the control data truncated. never ever seen that. I guess the real question is do I need to change the damn battery or is there an issue with ntpd with a large skew ? Thanks in advance. no. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: ntpd dies on startup if using -s option
* Paul de Weerd on Wed, Jun 17, 2009 at 11:34:38AM +0200: Just em0, which is connected to the LAN and gets all of its configuration via DHCP and rtsol. Is (one of) your ntp server(s) v6 only ? Do you have rtsol in your /etc/hostname.em0 ? Yes and yes. Do you get a lease immediately on boot or could there be some delay ? It sounds like you don't have proper connectivity yet when ntpd tries to start (either v4 or v6 (or both)). Verify this by putting something like 'ifconfig -a /tmp/ifc.out' in /etc/rc.local. As far as I glanced, the rtsol lease should already be present when ntpd tries to start, or at least the machine already knows where to reach the v6 gateway. But this is from memory; I will test it as soon as I get back to the machine in question. If I *don't* go with rtsol but e.g. let aiccu set up a gif-tunnel, ntpd get's up cleanly, sees that there's no way to reach the v6-servers (yet) (since aiccu would be invoked from rc.local, thus way after ntpd), syncs to the v4 ones, and some time later (successfully) starts connecting to the v6 ones. s//un
