January 2007 - Darwin-kernel

Performance counters...
by Michael Burbidge 24 Jan '07

24 Jan '07

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com Is there anything similar in Darwin? Thanks, Michael- _______________________________________________ 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.… Does darwin have a mechanism for monitoring various performance characteristics of an application. Windows supports a number of what they call performance counters. Applications can customize and extend this mechanism with their own custom counters. There is a monitoring application called perfmon that can track and report both system supported and custom performance counters. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Intel kernel build instructions disappeared
by Quinn 24 Jan '07

24 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Also, it would be more convenient to me to use a PowerPC machine to run the gdb when debugging my Intel machine over Internet. Does that work? Yes. This is the setup I have in my office. One gotcha is that you have to run GDB with the "-arch i386" flag. 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 23:16 -0800 23/1/07, Michael Crawford wrote: This email sent to site_archiver(a)lists.apple.com

1 0

Intel kernel build instructions disappeared
by Michael Crawford 24 Jan '07

24 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=f1aJBb2pVqGPevIOoEtrfA7bN+EsRy85jW8IxAl+pFH3lWc6JrPSRVPLm+xMY1rZ3GPVFJWLB9MCSdC/XO4JSYTEUGBFL7YSFxwK+IJjgOXKfNUA0hqIE0ku3V7c3dgWncoTyRB5n/lAhMDifbnWpjNYIl6HzJ8DQnGdq9hv7gQ= Hi, At http://kernel.macosforge.org/ there is a link to the Intel kernel build instructions. But the file it links to, http://kernel.macosforge.org/intel-build-instructions.html is not found. Has it been moved? I even tried finding it in The Wayback Machine, but it wasn't there either. Also, it would be more convenient to me to use a PowerPC machine to run the gdb when debugging my Intel machine over Internet. Does that work? If not there is another Intel machine I can use, but I'd like not to have to. Thanks! Mike -- Michael David Crawford mdcrawford at gmail dot com Enjoy my art, photography, music and writing at http://www.geometricvisions.com/ --- Free Music Downloads --- _______________________________________________ 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: in_cksum_offset(), in_delayed_cksum_offset() question
by Bhavesh Davda 23 Jan '07

23 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=RpyKREDXIMm1WMs3EUDEMC04Iqh077h2ncbhz9MNlHFwHVvYLLlL0r4Nq6eV/jdZltMuWlk6cIpvKO2m+RiCTpUHGvCQHjZBfW5tXOQH/TsSUlnsZUkAH5QuhY1JbRtOYbX/5GXRxSbL4Q1XPb4f5pjbc3vO8b4w4HtkIdPhn3w= Date: Tue, 23 Jan 2007 10:29:37 -0800 From: Kevin Brock <apple(a)kevin.com> Subject: Re: in_cksum_offset(), in_delayed_cksum_offset() question To: Adi Masputra <adi(a)apple.com> Cc: Darwin Kernel <darwin-kernel(a)lists.apple.com> Message-ID: <67D4482D-7F4D-49A7-9148-4323355B7BD8(a)kevin.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jan 23, 2007, at 10:19 AM, Adi Masputra wrote: > > Yes, this was a long-standing bug that has been fixed recently along > with the mbuf_outbound_finalize() byte-ordering issue. The fix should > be available fairly soon. It sounds like mbuf_outbound_finalize won't work at all with certain packets (large pings, for example). I knew I had to do workarounds for byte order problems with the function, but I hadn't realized that it was completely broken... To work generically with 10.4.8 and previous kernels it sounds like I need to do my own implementation of mbuf_outbound_finalize(). Kevin Brock brock(a)kevin.com Welcome to the club :) I had to do the same: walk the mbuf chains and do my own TCP/UDP/IPv4 header checksum computation. I was seeing the same "freeing free mbuf" panics after calling mbuf_outbound_finalize() on Intel Macs, and I noticed the same pattern: only happened when the mbuf was chained with the DLIL header in the pkthdr mbuf, and the rest of the payload split into one or more mbufs in that chain. -- Bhavesh P. Davda _______________________________________________ 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: in_cksum_offset(), in_delayed_cksum_offset() question
by Kevin Brock 23 Jan '07

23 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Yes, this was a long-standing bug that has been fixed recently along with the mbuf_outbound_finalize() byte-ordering issue. The fix should be available fairly soon. Kevin Brock brock(a)kevin.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.… On Jan 23, 2007, at 10:19 AM, Adi Masputra wrote: It sounds like mbuf_outbound_finalize won't work at all with certain packets (large pings, for example). I knew I had to do workarounds for byte order problems with the function, but I hadn't realized that it was completely broken... To work generically with 10.4.8 and previous kernels it sounds like I need to do my own implementation of mbuf_outbound_finalize(). This email sent to site_archiver(a)lists.apple.com

1 0

Re: in_cksum_offset(), in_delayed_cksum_offset() question
by Adi Masputra 23 Jan '07

23 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Kevin, Yes, this was a long-standing bug that has been fixed recently along with the mbuf_outbound_finalize() byte-ordering issue. The fix should be available fairly soon. Adi On Jan 23, 2007, at 10:13 AM, Kevin Brock wrote: Kevin Brock apple(a)kevin.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/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 Both of these take an offset for the IP header, and then try to find the mbuf in the chain that contains the IP header. What I was wondering about was the line below: if(m)... This first loop occurs in both of the functions. It looks as though the function will simply return if the IP header isn't in the first mbuf. It should be if(!m), to detect the condition where we've reached the end of the mbuf without finding the IP offset... Am I missing something here? If it simply returns any time the IP header isn't in the first mbuf, then mbuf_outbound_finalize, which calls these functions, will clear the checksum request flags without actually doing anything. void in_delayed_cksum_offset(struct mbuf *m, int ip_offset) { struct ip *ip; u_short csum, offset; while (ip_offset > m->m_len) { ip_offset -= m->m_len; m = m->m_next; if (m) { printf("in_delayed_cksum_withoffset failed - ip_offset wasn't in the packet\n"); return; } } This email sent to adi(a)apple.com smime.p7s

1 0

in_cksum_offset(), in_delayed_cksum_offset() question
by Kevin Brock 23 Jan '07

23 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Kevin Brock apple(a)kevin.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.… Both of these take an offset for the IP header, and then try to find the mbuf in the chain that contains the IP header. What I was wondering about was the line below: if(m)... This first loop occurs in both of the functions. It looks as though the function will simply return if the IP header isn't in the first mbuf. It should be if(!m), to detect the condition where we've reached the end of the mbuf without finding the IP offset... Am I missing something here? If it simply returns any time the IP header isn't in the first mbuf, then mbuf_outbound_finalize, which calls these functions, will clear the checksum request flags without actually doing anything. void in_delayed_cksum_offset(struct mbuf *m, int ip_offset) { struct ip *ip; u_short csum, offset; while (ip_offset > m->m_len) { ip_offset -= m->m_len; m = m->m_next; if (m) { printf("in_delayed_cksum_withoffset failed - ip_offset wasn't in the packet\n"); return; } } This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel Panics & kernel controls
by Greg 23 Jan '07

23 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com - Greg On Jan 22, 2007, at 4:31 PM, Matt Darland wrote: On Jan 21, 2007, at 10:22 PM, Greg wrote: static errno_t send_upbound_data( u_int32_t sock, mbuf_t indata ) { mbuf_t hdr; mbuf_gethdr( MBUF_WAITOK, MBUF_TYPE_DATA, &hdr ); mbuf_setnext( hdr, indata ); mbuf_pkthdr_setlen( hdr, BYTECOUNT_IN_INDATA_CHAIN ); return( error ); } ---- Matt On Jan 19, 2007, at 3:46 PM, Matt Darland wrote: ---- Matt _______________________________________________ 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.… Thanks, I am sending to the same unit number and so I do think that there probably is a concurrency issue, once I fix it (hopefully) I'll let you know (I'm definitely not calling ctl_enqueue more than 100 times/sec). I thought that your statements might have been the silver bullet but I don't think that I'm calling anything that implicitly consumes the mbuf chain before I free it. I think that the problem is occurring because ctl_enqueue is being called either too quickly or concurrently, so I will try to work around that (I was planning on doing it anyway) and see if that stops the kernel panics. ctl_enqueuedata() internally does m_allocpacket_internal(M_NOWAIT) which can fail due to a low free mbuf pool, but it won't panic due to calling frequency. Concurrency may be an issue if you are sending data concurrently to the same 'unit number' (not sure about this; I'm not constrained by this requirement). 'Units' state are protected such that calling ctl_enqueueXXX() against different units is no problem. A possible alternative that I know works in 'high-traffic' usage (> 100 ctl_enqueuembuf() calls/sec and >50Mbits/sec) is to do mbuf allocation yourself and use ctl_enqueuembuf(). The first mbuf in your chain MUST be a 'packet header' type mbuf. This isn't documented, but the darwin source in kern_control.c/ctl_enqueuembuf () assumes the existence of a packet header. For example: errno_t error = ctl_enqueuembuf( gKctlRef, sock, hdr, CTL_DATA_EOR ); if( error != ENOBUFS ) { /* Mbuf chain consumed. */ if( error ) { printf( "com.mykext: ctl_enqueuembuf() = %d.\n", error ); } } else { /* Mbuf chain NOT consumed. Maybe create a timer to retry send? */ /* ...or delete using mbuf_freem( hdr ); */ } When you get the mbuf from the ctl_send handler your kext owns the mbuf and is responsible for disposal. However, disposal can mean things other than directly calling mbuf_freem(), e.g. ctl_enqueuembuf(), sock_sendmbuf(), or any other routine that implicitly consumes an mbuf chain. Also, if you are modifying mbuf payloads, be aware of mbufs with 'external data' (often referred to as mbuf clusters). External data is payload data that is referenced by multiple mbufs, and you could be modifying data out from underneath another part of the OS. This email sent to site_archiver(a)lists.apple.com

1 0

An mbuf_outbound_finalize bug that's *not* byte-order related?
by Kevin Brock 23 Jan '07

23 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I don't know why mbuf_outbound_finalize *only* on these packets was leaving the mbuf trashed, but I have a feeling it has to do with the mbuf pull-up code in in_delayed_cksum_offset, and the fact that these mDNS mbufs are chained mbufs, with the pkthdr mbuf containing the L2 header, and the rest of the IP+UDP+payload packet in the next mbuf in the chain. So I suspect mbuf_outbound_finalize is probably broken for all chained mbufs where the pkthdr mbuf doesn't contain the IP header, but I can't point you to the line of code in the xnu/bsd source that is the culprit, sorry! /*! . . . I built with this entry and ran. Kevin Brock apple(a)kevin.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.… On Jan 2, 2007, at 10:45 AM, Bhavesh Davda wrote: On a dual processor G5 I end up with a kernel panic if I call mbuf_outbound_finalize on a packet with multiple non-external-data mbufs. The distinguishing feature of these chains is that the IP header is not in the same mbuf as the MAC header. In a chain that has data in external buffers the MAC header and the IP header appear to be in the same buffer. When the IP header isn't in the first mbuf mbuf_outbound_finalize calls mbuf_pullup to get everything in one buffer... I recently ran into a bug where calling mbuf_pullup on 10.4.8 appears to cause the mbuf to be freed if the mbuf is multiple non-external- data mbufs, but doesn't return an error code--I was going to ask the list about that one when I ran across this problem. Finally stopped trying to get the IP header into the first buffer, and walked the chain to find it instead. Unfortunately there's no way I can tell mbuf_outbound_finalize to do that :-( There's no byte order problem on G*, and I wanted to eliminate other code as a possible problem, so I stripped the interface filter output entry down to: @result Return: 0 - The caller will continue with normal processing of the packet. EJUSTRETURN - The caller will stop processing the packet, the packet will not be freed. Anything Else - The caller will free the packet and stop processing. */ errno_t filter_output(void* cookie, ifnet_t interface, protocol_family_t protocol, mbuf_t *data) { mbuf_outbound_finalize(*data, PF_INET, ETHER_HDR_LEN); return 0; } Pinging with small packets is fine. I get a panic if I simply say ping -s 200 <some address>. The actual limit for not crashing is actually ping -s 160, which fills a single mbuf's data buffer. This example code works fine on multiple other systems, G4, and G5 (single processor). The only difference I noticed from the G4 and G5 systems that work is that the G5 Dual Power Mac that crashes has flags MBUF_CSUM_REQ_IP and MBUF_CSUM_REQ_UDP or MBUF_CSUM_REQ_TCP set. So on the only system where this code will actually *do* anything, it's crashing... The kernel panic says "freeing freed mbuf". This looks *exactly* like the crashes I was seeing when I called mbuf_pullup. No error code, but the mbuf appears to have been freed... Is there some obscure (or obvious) problem with the stripped down code above? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Kernel Panics & kernel controls
by Matt Darland 22 Jan '07

22 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 21, 2007, at 10:22 PM, Greg wrote: static errno_t send_upbound_data( u_int32_t sock, mbuf_t indata ) { mbuf_t hdr; mbuf_gethdr( MBUF_WAITOK, MBUF_TYPE_DATA, &hdr ); mbuf_setnext( hdr, indata ); mbuf_pkthdr_setlen( hdr, BYTECOUNT_IN_INDATA_CHAIN ); return( error ); } ---- Matt On Jan 19, 2007, at 3:46 PM, Matt Darland wrote: ---- Matt _______________________________________________ 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 thought that your statements might have been the silver bullet but I don't think that I'm calling anything that implicitly consumes the mbuf chain before I free it. I think that the problem is occurring because ctl_enqueue is being called either too quickly or concurrently, so I will try to work around that (I was planning on doing it anyway) and see if that stops the kernel panics. ctl_enqueuedata() internally does m_allocpacket_internal(M_NOWAIT) which can fail due to a low free mbuf pool, but it won't panic due to calling frequency. Concurrency may be an issue if you are sending data concurrently to the same 'unit number' (not sure about this; I'm not constrained by this requirement). 'Units' state are protected such that calling ctl_enqueueXXX() against different units is no problem. A possible alternative that I know works in 'high-traffic' usage (> 100 ctl_enqueuembuf() calls/sec and >50Mbits/sec) is to do mbuf allocation yourself and use ctl_enqueuembuf(). The first mbuf in your chain MUST be a 'packet header' type mbuf. This isn't documented, but the darwin source in kern_control.c/ctl_enqueuembuf() assumes the existence of a packet header. For example: errno_t error = ctl_enqueuembuf( gKctlRef, sock, hdr, CTL_DATA_EOR ); if( error != ENOBUFS ) { /* Mbuf chain consumed. */ if( error ) { printf( "com.mykext: ctl_enqueuembuf() = %d.\n", error ); } } else { /* Mbuf chain NOT consumed. Maybe create a timer to retry send? */ /* ...or delete using mbuf_freem( hdr ); */ } When you get the mbuf from the ctl_send handler your kext owns the mbuf and is responsible for disposal. However, disposal can mean things other than directly calling mbuf_freem(), e.g. ctl_enqueuembuf(), sock_sendmbuf(), or any other routine that implicitly consumes an mbuf chain. Also, if you are modifying mbuf payloads, be aware of mbufs with 'external data' (often referred to as mbuf clusters). External data is payload data that is referenced by multiple mbufs, and you could be modifying data out from underneath another part of the OS. This email sent to site_archiver(a)lists.apple.com

1 0