In message <I01yoy.BKB@tac.nyc.ny.us>, you write: 

-> In article <I01wto.I6L@tac.nyc.ny.us>,
-> Christos Zoulas <christos@tac.gw.com> wrote:
-> >In article <40E0DA72.1000003@distal.com>,
-> >Chris Ross <cross+netbsd@distal.com> wrote:
-> >>john heasley wrote:
-> >>
-> >>> this is PR lib/25892.  Not sure what the problem is, but it appears
-> >>> to actually be occuring within the libc resolver.
-> >>> 
-> >>> you can likely work around by rolling your libc back to ~12.117 or
-> >>> using addresses instead of names in your ntpd.confg.
-> >>
-> >>   Okay. I've now confirmed that this bug doesn't occur when I
-> >>use addresses rather than hostnames in the ntp.conf file.  Hrm.
-> >
-> >something is wrong with the stack. if I change all the char t*[*]
-> >to static in the resolver, it works. I am compiling a kernel with
-> >64M stack limit.
-> 
-> I just fixed it. It was ntpd's fault for reducing the stack to only 80K
-> which is not enough for a 64 bit machine and the new resolver.

Ooh, thanks for fixing that (and to Chris for bringing it up); I'd just
updated the kernel on my U5 after almost 6 mos of uptime and since I had
to rebuild sysctl (which requires a new libc) I had this happen to me as
well... and of course I didn't actually notice ntpd wasn't running until
Chris mentioned it here :-)

Thanks!
--rafal

----
Rafal Boni                                                     rafal@pobox.com
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill