October 2007 - Darwin-kernel

Re: ctl_enqueuedata() woes
by Adi Masputra 04 Oct '07

04 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com How are you calling ctl_enqueuedata() -- i.e. what are its parameters? Adi On Oct 3, 2007, at 9:26 AM, Karl Pickett wrote: An example where I bumped the rcv_buff up to 60000: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/adi%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com I have modified the tcplognke example and it was pleasant sailing until now. I am sending packets to userspace that are about 2020 bytes long. Userspace reads each packet and responds with a setsockopt() call with a 2k structure. When a burst of packets gets sent, some packets will fail to be received by user space but no error was indicated from ctl_enqueuedata() Calling ctl_getenqueuespace(), the packets end up disappearing when ever the queuespace is not the maximum. Bumping up the socket recvbuf from 8k to 60k did not help one bit! Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 35: ret 0, space=60000 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 36: ret 0, space=57924 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 37: ret 0, space=55848 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 38: ret 0, space=53772 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 39: ret 0, space=51696 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 40: ret 0, space=49620 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 41: ret 0, space=47544 Oct 2 17:16:21 karls-power-mac-g4 kernel[0]: ctl_enqueuedata 42: ret 0, space=60000 Only packets 35 and 42 were received by userspace! The rest went to a bit bucket somewhere, and as you can see the ret 0 indicates no error by ctl_enqueuedata. In some cases when the space was completely exhausted ctl_enqueuedata would return an error, but otherwise the packets would just disappear when ever the enqueuespace was not at max. -- Karl Pickett "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin This email sent to adi(a)apple.com smime.p7s

1 0

Re: ctl_enqueuedata() woes
by Brian Bergstrand 03 Oct '07

03 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 3, 2007, at 7:58 PM, Josh Graessley wrote: On Oct 3, 2007, at 9:55 AM, Brian Bergstrand wrote: On Oct 3, 2007, at 7:26 PM, Karl Pickett wrote: Brian Bergstrand <http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I have modified the tcplognke example and it was pleasant sailing until now. I am sending packets to userspace that are about 2020 bytes long. Userspace reads each packet and responds with a setsockopt() call with a 2k structure. When a burst of packets gets sent, some packets will fail to be received by user space but no error was indicated from ctl_enqueuedata() Calling ctl_getenqueuespace(), the packets end up disappearing when ever the queuespace is not the maximum. Bumping up the socket recvbuf from 8k to 60k did not help one bit! ut otherwise the packets would just disappear when ever the enqueuespace was not at max. This is how control sockets work. Here's a way to get around the problem (if you can gracefully sleep that is): int retry = 3; retry_data: size_t recvsz = 0; if (0 == ctl_getenqueuespace(ctl_ref, ctlunit, &recvsz) && recvsz < datasize && retry > 0) { // msg q is full // Sleep one quantum giving the client a chance to wake struct timespec ts = {0, 10000000}; (void)msleep(NULL, NULL, PSOCK, __FUNCTION__, &ts); retry--; goto retry_data; } err = ctl_enqueuedata(...); Please don't do this. If you're running on the input thread you're going to hurt network performance. -josh Well, for me, this code is in a separate thread not involved in the network stack. But if we aren't supposed to do this in a network callback (which again, I'm not doing) what are we supposed to do? As Karl pointed out, ctl_enquedata doesn't handle this case itself, so we have to. This email sent to site_archiver(a)lists.apple.com

1 0

Re: ctl_enqueuedata() woes
by Karl Pickett 03 Oct '07

03 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=IPr99WsreqcCWUCG8DVbhgw3WwY4/dFOcIX1swkWu6A=; b=rD00xGdvrBSYudCG4FVGmMviGjCjzxSp5cGDcz90EJm6Cr6w/DBonePR89cOUPAE5DMWPQJtuJmlhQqPRAqCKWJoZBpxVo/747sC2J/lqieJQUT+iZFF2H/r0F2ySmsh62BLThgxKpHQejRQYfeBgH/ALGJWyEYbN/7h7lrN9d4= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=nbX9NnUi9orMZsvdQD77FAUppqFXRDytL3acrCCSliuIWcRn+P0EA8/N48X+aokyfCkV92sGn2Rafl636VkOLZs5k0N+ftewseQZ/KFk+TKQLfG5egrKr+cz71ZyQ4M/qC9Z+4JLGqhYqx4GGpnGfxl6VcEBlTclRpCun8DlBMQ= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: ctl_enqueuedata() woes
by Josh Graessley 03 Oct '07

03 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 3, 2007, at 9:55 AM, Brian Bergstrand wrote: On Oct 3, 2007, at 7:26 PM, Karl Pickett wrote: -josh _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I have modified the tcplognke example and it was pleasant sailing until now. I am sending packets to userspace that are about 2020 bytes long. Userspace reads each packet and responds with a setsockopt() call with a 2k structure. When a burst of packets gets sent, some packets will fail to be received by user space but no error was indicated from ctl_enqueuedata() Calling ctl_getenqueuespace(), the packets end up disappearing when ever the queuespace is not the maximum. Bumping up the socket recvbuf from 8k to 60k did not help one bit! [snip] Only packets 35 and 42 were received by userspace! The rest went to a bit bucket somewhere, and as you can see the ret 0 indicates no error by ctl_enqueuedata. In some cases when the space was completely exhausted ctl_enqueuedata would return an error, but otherwise the packets would just disappear when ever the enqueuespace was not at max. This is how control sockets work. Here's a way to get around the problem (if you can gracefully sleep that is): int retry = 3; retry_data: size_t recvsz = 0; if (0 == ctl_getenqueuespace(ctl_ref, ctlunit, &recvsz) && recvsz < datasize && retry > 0) { // msg q is full // Sleep one quantum giving the client a chance to wake struct timespec ts = {0, 10000000}; (void)msleep(NULL, NULL, PSOCK, __FUNCTION__, &ts); retry--; goto retry_data; } err = ctl_enqueuedata(...); Please don't do this. If you're running on the input thread you're going to hurt network performance. This email sent to site_archiver(a)lists.apple.com

1 0

Re: ctl_enqueuedata() woes
by Brian Bergstrand 03 Oct '07

03 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Oct 3, 2007, at 7:26 PM, Karl Pickett wrote: HTH. Brian Bergstrand <http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2 _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I have modified the tcplognke example and it was pleasant sailing until now. I am sending packets to userspace that are about 2020 bytes long. Userspace reads each packet and responds with a setsockopt() call with a 2k structure. When a burst of packets gets sent, some packets will fail to be received by user space but no error was indicated from ctl_enqueuedata() Calling ctl_getenqueuespace(), the packets end up disappearing when ever the queuespace is not the maximum. Bumping up the socket recvbuf from 8k to 60k did not help one bit! [snip] Only packets 35 and 42 were received by userspace! The rest went to a bit bucket somewhere, and as you can see the ret 0 indicates no error by ctl_enqueuedata. In some cases when the space was completely exhausted ctl_enqueuedata would return an error, but otherwise the packets would just disappear when ever the enqueuespace was not at max. This is how control sockets work. Here's a way to get around the problem (if you can gracefully sleep that is): int retry = 3; retry_data: size_t recvsz = 0; if (0 == ctl_getenqueuespace(ctl_ref, ctlunit, &recvsz) && recvsz < datasize && retry > 0) { // msg q is full // Sleep one quantum giving the client a chance to wake struct timespec ts = {0, 10000000}; (void)msleep(NULL, NULL, PSOCK, __FUNCTION__, &ts); retry--; goto retry_data; } err = ctl_enqueuedata(...); This email sent to site_archiver(a)lists.apple.com

1 0

ctl_enqueuedata() woes
by Karl Pickett 03 Oct '07

03 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=3dDrOa/n8ShrV9Qr3gW9iOzxwc4VbgDaqSOJB7XTlCc=; b=gCZFYg3fnQtxvhmJ99pezljSZPmiVkcLCc3vjK/SDP1yhg6YTqbVWSFb9hqnxBN0j8H1B55X4D1tfNu6dCqHJfQqHrKhzaIrWjhGPzGVHZOzaPtAzetF4TX50NIB6IDi3AT/I3FZss6tZ8d0rL6KaLQsZL3rCFTcZPcAIbDLJ1g= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=n9otARFA1fbaLse6f73MPOT5qMXDV7m9y4AlrubT4uTE/7GwIvR70m12SBmEjJsb/NYnYgfZTUPkK7DISvP1n4K2MzzDOgA8dh5Glj9yZeoLQHx6/NcYZexpUaMmfgyfJ29FH4yE/GCcHuCPqRZnsxkfRPr9VuNmDK9dREXNMn4= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Bug in tcplognke example?
by Karl Pickett 03 Oct '07

03 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; bh=/NjHHvL0F7u5fKDtCAbVM9NZ1SUs1+fqeXi/XpBAbY4=; b=P1v10P4OpkTZLE1/4xKjV/70t/K7NNn3/ncYbKOIZVPYev+zfVduSJxlmcoBbB66t709HsU610Kz+mKQ2TuK2UeCGhotuxt7CBgq6LkfWi6j9QXQ1+38ybdBUsJZi9Pez6dsCgj3C/PJ2WLVcCSS3wULowLw0cZv4Zgf8DklPhE= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=WzLYSF0kjRr1RZI4HqRUoFpq4t703h/szSmzt2hph0n2u+6sSoTrRB6L4rfO9g+2ne5JgA9cypWiD5jr8cNQNAVFqVWrdTn/MV76YwRo19XyI/jTocMe5QEDTsHwm+t8k6qG+/TDxPdlCZcfjkxOQuxtuJ9HhzFLaNTsvmXrxHU= _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Dump panic log after boot
by Jonas Maebe 03 Oct '07

03 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 03 Oct 2007, at 11:28, Quinn wrote: kr = task_set_exception_ports( mach_task_self(), EXC_MASK_ALL, MACH_PORT_NULL, EXCEPTION_DEFAULT, 0 ); Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I don't know how to solve your panic log question, but I have an alternative approach that might help you avoid this problem in the future. Rather than disabling crash reporter globally, disable it for the test programs. If you add the following line to main, crash reporter won't hear about any crashes. Thanks, I'll add that code to the programs. Although I have the same problem with our compiler, and while I don't want it to generate crash logs on my machine, crashreporter logs from users can be helpful. I guess I should file a radar requesting a fourth crashreporter mode (log kernel panics but nothing else). This email sent to site_archiver(a)lists.apple.com

1 0

Re: Dump panic log after boot
by Jonas Maebe 03 Oct '07

03 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 03 Oct 2007, at 11:12, Jonas Maebe wrote: Oops, that should read 10.4.10. Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… but that still did not create a panic log. Is there a way to still recover the panic log from nvram (it's on a G5 running 10.5.10)? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Dump panic log after boot
by Quinn 03 Oct '07

03 Oct '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com kr = task_set_exception_ports( mach_task_self(), EXC_MASK_ALL, MACH_PORT_NULL, EXCEPTION_DEFAULT, 0 ); S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… At 11:12 +0200 3/10/07, Jonas Maebe wrote: I have crashreporterd disabled on my machine, because I regularly run (test) programs which trigger hardware exceptions but catch them and deal with them via Unix signals (and crashreporterd nevertheless insists on dumping crash logs in such situations because it can't know those exceptions are caught at the BSD level, which is pretty annoying even if it's set not to display dialog boxes). I don't know how to solve your panic log question, but I have an alternative approach that might help you avoid this problem in the future. Rather than disabling crash reporter globally, disable it for the test programs. If you add the following line to main, crash reporter won't hear about any crashes. This email sent to site_archiver(a)lists.apple.com

1 0