Hello Danny, On Monday, May 8, 2006 at 3:32:29 +0000, Danny Mayer wrote:
> Danny Mayer wrote: >> Please try with -D2 and not just -d. It should print out more >> information. If it is what I think then you are just looping through >> the same thing over and over again and you never get out. Here it is with -D2, beginning just before the storm: | sendpkt(fd=22 dst=192.168.7.5, src=192.168.7.10, ttl=0, len=48) | transmit: at 3 192.168.7.10->192.168.7.5 mode 3 | poll_update: at 3 192.168.7.5 flags 0601 poll 6 burst 8 last 3 next 5 | get_full_recv_buffer() called and full_recvbufs is 1 | receive: at 3 192.168.7.10<-192.168.7.5 flags 19 restrict 000 | receive: at 3 192.168.7.10<-192.168.7.5 mode 4 code 1 auth 0 | addto_syslog: peer 192.168.7.5 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) | peer 192.168.7.5 event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) | clock_filter: n 1 off -0.009194 del 0.003643 dsp 7.939454 jit 0.000002, age 0 | filegen 2 3356085458 0 3356035200 | receive: at 3 192.168.7.10<-192.168.7.5 flags 19 restrict 000 | receive: at 3 192.168.7.10<-192.168.7.5 mode 4 code 1 auth 0 And the last 2 lines are repeated thousands times per second, until ^C. > Also change the following line in ntpd (line 961) from: > while (full_recvbuffs()) to: while (full_recvbuffs() > 0) No such line in ntp-dev-4.2.1p247-RC? ntpd/ntpd.c doesn't seem to contain any "full_recvbuffs". Lines 961 and next are: | rbuf = get_full_recv_buffer(); | while (rbuf != NULL) I don't know if it's relevant, but a recursive grep finds "full_recvbufs" spelled both with one and two "f". Serge. -- Serge point Bets arobase laposte point net _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
