[ntp:hackers] recvbuf fixes
Brian Utterback
brian.utterback at sun.com
Fri Dec 9 19:14:17 UTC 2005
Danny Mayer wrote:
> Harlan Stenn wrote:
>> Folks,
>>
>> A tarball of Danny's current fixes can be found at the UDel download
>> site in ~ftp/pub/ntp/ntp4/testing/ntp-4.2.0b.tar.gz .
>>
>> We have one Sun/Solaris10 machine that seems to go into a loop with this
>> code and have not yet figured out what the problem is.
>>
>> We'd appreciate whatever debug assistance we can get on this one -
>> fixing the recvbuff problem is blocking the release of 4.2.1 .
>>
>
> The problem is when using ntpd -g -N in starting it up. It is not a
> problem if -N is NOT used. I'm no longer sure that recvbuffs has
> anything to do with it. Having it running at the highest level permitted
> by the O/S is what's causing the problem and I've only really been
> testing it on Solaris 10.
>
> Brian, any thoughts on this?
Okay, I tried out the tarball that Harlan posted, and lo and behold,
it does indeed suck up the entire system. Luckily I am using a two
CPU system and it can only get one CPU, so I am able to look at it.
Here is a short truss with subroutines included:
/1 at 1: -> get_full_recv_buffer(0x0, 0xffff, 0x384, 0x134400)
/1 at 1: -> block_sigio(0x0, 0x0, 0x0, 0x0)
/1: lwp_sigmask(SIG_SETMASK, 0x00200000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- block_sigio() = 1
/1 at 1: -> unblock_sigio(0x1, 0x134400, 0x134400, 0x134400)
/1: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- unblock_sigio() = 0
/1 at 1: <- get_full_recv_buffer() = 0
/1 at 1: -> block_io_and_alarm(0x0, 0xffff, 0x384, 0x134400)
/1: lwp_sigmask(SIG_SETMASK, 0x00202000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- block_io_and_alarm() = 0
/1 at 1: -> full_recvbuffs(0x0, 0xffff, 0x384, 0x134400)
/1 at 1: <- full_recvbuffs() = 0
/1 at 1: -> unblock_io_and_alarm(0x0, 0xffff, 0x384, 0x134400)
/1: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- unblock_io_and_alarm() = 0
/1 at 1: -> get_full_recv_buffer(0x0, 0xffff, 0x384, 0x134400)
/1 at 1: -> block_sigio(0x0, 0x0, 0x0, 0x0)
/1: lwp_sigmask(SIG_SETMASK, 0x00200000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- block_sigio() = 1
/1 at 1: -> unblock_sigio(0x1, 0x134400, 0x134400, 0x134400)
/1: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- unblock_sigio() = 0
/1 at 1: <- get_full_recv_buffer() = 0
/1 at 1: -> block_io_and_alarm(0x0, 0xffff, 0x384, 0x134400)
/1: lwp_sigmask(SIG_SETMASK, 0x00202000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- block_io_and_alarm() = 0
/1 at 1: -> full_recvbuffs(0x0, 0xffff, 0x384, 0x134400)
/1 at 1: <- full_recvbuffs() = 0
/1 at 1: -> unblock_io_and_alarm(0x0, 0xffff, 0x384, 0x134400)
/1: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- unblock_io_and_alarm() = 0
/1 at 1: -> get_full_recv_buffer(0x0, 0xffff, 0x384, 0x134400)
/1 at 1: -> block_sigio(0x0, 0x0, 0x0, 0x0)
/1: lwp_sigmask(SIG_SETMASK, 0x00200000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- block_sigio() = 1
/1 at 1: -> unblock_sigio(0x1, 0x134400, 0x134400, 0x134400)
/1: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- unblock_sigio() = 0
/1 at 1: <- get_full_recv_buffer() = 0
/1 at 1: -> block_io_and_alarm(0x0, 0xffff, 0x384, 0x134400)
/1: lwp_sigmask(SIG_SETMASK, 0x00202000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- block_io_and_alarm() = 0
/1 at 1: -> full_recvbuffs(0x0, 0xffff, 0x384, 0x134400)
/1 at 1: <- full_recvbuffs() = 0
/1 at 1: -> unblock_io_and_alarm(0x0, 0xffff, 0x384, 0x134400)
/1: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- unblock_io_and_alarm() = 0
/1 at 1: -> get_full_recv_buffer(0x0, 0xffff, 0x384, 0x134400)
/1 at 1: -> block_sigio(0x0, 0x0, 0x0, 0x0)
^C/1: lwp_sigmask(SIG_SETMASK, 0x00200000, 0x00000000) = 0xFFBFFEFF
[0x0000FFFF]
/1 at 1: <- block_sigio() = 1
So, apparently we have a bit of a busy loop here. I don't see any actual
I/O calls in there anywhere.
--
blu
"Having them stolen may become our distribution model..."
Nicolas Negroponte on the Hundred Dollar Laptop.
----------------------------------------------------------------------
Brian Utterback - OP/N1 RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
More information about the hackers
mailing list