January 2007 - Darwin-kernel

Re: Understanding cores...
by Andreas Fink 11 Jan '07

11 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.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

1 0

IODemoryDescriptor->prepare() Performance relateted to the kIODirection?
by devmaillists 11 Jan '07

11 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hello Darwin-kernel List, Thank you very much. Jürgen _______________________________________________ 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 some question regarding the speed of IODemoryDescriptor- >prepare(). Does the direction have an impact on the speed "prepare" needs to complete? And further more does the direction have an impact on DMA speed a PCIe Busmaster can reach on the prepared memory? This email sent to site_archiver(a)lists.apple.com

1 0

Re: TCP, and clamping MSS..?
by Andrew Gallatin 11 Jan '07

11 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Vincent Lubet writes: > Andrew, > > This is an optimization that is simple missin in xnu -- thanks for > bringing it to our attention. > > Feel free to file an enhancement request at http:// > bugreporter.apple.com/ to make sure this won't fall through the cracks. > Thanks Vince.. I've filed problem id 4919145. FWIW, it looks like the MSS clamping code was removed sometime between 10.2 and 10.3. I've never really understood why it helps so much. This isn't just my NIC that it helps for. See the thread starting at http://lists.freebsd.org/pipermail/freebsd-net/2004-January/002594.html where I actually proposed removing it, and found that it really did help! Do you have any intuition on why keeping things nicely aligned helps so much? Linux, on the same hardware, does not need to clamp the MTU, and easily maxes out the 10GbE link with far lower CPU utilization. Is the BSD stack just that much more sensitive to alignment? Drew _______________________________________________ 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: Understanding cores...
by Terry Lambert 11 Jan '07

11 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hello Derek, objptr_t foo; ... foo = new_foo(); ... discard_foo(foo); ... foo->xxx = yyy; /* Use after free!!!!! */ void discard_foo(objptr_t ptr) { ... free(ptr); /* or whatever free function we use */ ... } This is inherently unsafe; but say we change it to: ... discard(&foo); ... and define it as: void discard_foo objptr_t *ptrptr) { objptr_t ptr = *ptrptr; *ptrptr = (void *)(7); /* characteristic illegal value */ ... free(ptr); /* or whatever free function we use */ ... } -- Terry _______________________________________________ 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 10, 2007, at 11:05 PM, Andreas Fink wrote: On 09.01.2007, at 19:28, Derek Kumar wrote: On Jan 8, 2007, at 4:05 PM, Michael Tuexen wrote: Well on that system the NKE is load always, because it is required by the application running on that Mac Pro. In the meantime another system was setup (on a different hardware) the it also crashes a lot. BTW: A lot means a couple of times per day. And yes, the cores we get (using a core dump server), are all like this (some pointed to bugs in the NKE in the past, but these could be fixed, then also SCTP.kext was explicitly mentioned in the paniclog). Any idea how to narrow down the problem? If the EIP values in the "paniclog" register dump are identical/ similar across all the crashes you've observed (note that "unresolved kernel trap" is just a generic label), and only occur when your driver is loaded, it's likely to be memory corruption as I noted previously. Is it always an EBP based access (typically a local or parameter) in idle_thread() that's causing the fault? The loop in idle_thread() briefly enables interrupts and disables them, so if you have an interrupt filter routine (that executes at interrupt context) that could be another point where corruption could occur (in addition to the the saved context at the base of the thread's kernel stack I mentioned previously--corruption of the register context below the interrupt stack frame that contains the saved value of the EBP register, for instance). Unfortunately, there's no single magic bullet when it comes to identifying sources of memory corruption of this type--determining the patterns and location of corruption and binary search via logging/tracing is one approach (after carefully walking through your code to look for erroneous stores to memory, bad DMA bounds, stack overflows etc.; I don't think page protection/debug register type schemes to trap the bad store (assuming it's not a physical mode store) would be useful here since the register context would be very frequently accessed. Logic analyzers (very expensive) would be a last resort). The kernel trace facility (/usr/local/bin/trace - h) can tell you what events (such as interrupts and context switches) occurred on that processor, but given that it panics, you'd probably have to examine the trace buffer in memory (see xnu/ bsd/kern/kdebug.c in the kernel sources for the internals of the trace facility) to extract the last few trace events. Derek We now had the same crash on a XServe dual G5 which looks like the one below. We think to have spotted the real culprit in the meantime but its like fishing in the dark and wild guessing and hoping to have it fixed. But as we see several crashdumps a day from different machines, we will know pretty soon if we found it or not. But we want to be sure ;-). So is there anything useable we can follow on this gdb output which could give us some hints? Typically, you just have to design your code so that it either fails safe, or it fails locally. If you end up corrupting memory, or end up walking off a pointer into a non existent address, or an address of something that used to be allocated, but is now freed, you will get either memory corruption (if you happen to hit something that's there, or if a freed area is reused for another purpose), or you crash with a fault in kernel mode. In general, that's why all the documentation asks you to consider if you can write your code in user space instead of the kernel. When you are programming in the kernel, it is the same as programming in any other kernel, or in a single address space embedded system (e.g. DOS or some other non-protected mode OS). There are a number of techniques you can learn to prevent this biting you, or when it bites you, from biting too hard, but it's typically just a skill you have to master like any other skill. For example, if you allocate memory, make sure you create a zone for it and allocate from that. This makes the memory type-stable, so that f anything gets hosed, then your search area is limited to the code that touches the type of memory that got hosed. Another example is to scribble over freed objects before returning them to free lists, so that if you attempt to use the object after it's freed, you will end up with a very identifiable and distinctive error, rather than some random error. You can also use "corrupting frees". An example of a "corrupting free" would be if you had an object pointer, and used it like this: How would you change the design of this API to prevent the use after free? The easiest way would be to change discard_foo()'s definition and use... currently, the way it's used, it's apparent that we are doing: Now if we attempt to continue to use foo, we are going to see a crash on an odd address boundary, and we know that we allocate all our things at even addresses. So now we know we are continuing to use a pointer after freeing it. Further, since we guarantee that the pointer immediately goes out of scope, if it's a pointer in a structure, and is therefore globally visible, we are guaranteed that there won't be an interrupt routine or another thread accessing it out of the globally visible space after it's on its way to being freed, since if that happens, then whoever attempts to access it will crash. So we get several types of safety protection, pretty much for free, just by changing how we define our API. We might also decide to boot with cpus=1 on an SMP system, to make sure that any locking we forget to do against reentrancy won't bite us. This boots to multiuser with only a single CPU active. If you have race conditions, and you are seeing crashes, and you boot with a single CPU and all your problems mysteriously disappear, then it's a sure bet that you've failed to deal with some concurrency issue. Maybe you have a data structure that's used in multiple places, and you don't hold a mutex to serialize access to it. Or maybe you dereference part of a structure to et a flags value, then you perform a potentially blocking operation, someone else comes along while you are asleep and changes the flags out from under you, and then you make a bogus decision on the basis of the previous flags value, rather than it's current value. Or maybe you just forgot to mark a global pointer as "volatile" and are changing its value from another thread, and since it's being used in a loop, the compiler optimized it into a register, so its value never changes as far as the code is concerned (because you failed to give the optimization hint "volatile" to the compiler to prevent that). These are just a couple of examples of what you can do in your kernel code to make debugging problems easier, but there are lots of others. In general, and good programming text on embedded systems or kernel programming, or even programming for non-protected mode OS's, like DOS or very old version of MacOS, or in the Linux or FreeBSD kernel, etc., wil go into more detail than I can go into here. Then we are off to do the same under Leopard. (oh by the way, where can we checkout the sources of current leopard beta so we can verify our design?). You can't get the sources. We generally do not release xnu sources until after release, for reasons which should be obvious, if you think about them a little bit. If you need to test the KEXT and you are eligible for seeds (see <http://developer.apple.,com>), you can install one of the seed builds and load your KEXT into a binary seed kernel for testing. This email sent to site_archiver(a)lists.apple.com

1 0

kevent problems at exit
by Jones Curtis 11 Jan '07

11 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:mime-version:to:message-id:content-type:from:subject:date:x-mailer; b=fkMSOidMesoVxa8dBuoAVTNTswYcxj8m8KLP0CGCeAKMft+++Hh5YPqFas/rO6fC0VwT85NZYGmb3K+ij8J60j5XIxcmkui0ANGxtrEzQLWF5jMnI8v1CHLjRxxNrCNvNwXLwH5v/U8XeHeZ4S0z4FHsTLMY+UI6BNxFEvcz/AQ= -- Curtis Jones curtis.jones(a)gmail.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 Before I go through the hassle of trying to reproduce this problem in a reliable manner ... does anyone know of any problems pertaining to being blocked in a call to kevent() while another thread calls exit ()? At least I think that's what was going on. The result is that the process is zombied with launchd (ppid=1) as the parent. smime.p7s

1 0

Re: Understanding cores...
by Andreas Fink 11 Jan '07

11 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On 09.01.2007, at 19:28, Derek Kumar wrote: On Jan 8, 2007, at 4:05 PM, Michael Tuexen wrote: Hello Derek, for CPU 1 for CPU 0 _______________________________________________ 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.… Well on that system the NKE is load always, because it is required by the application running on that Mac Pro. In the meantime another system was setup (on a different hardware) the it also crashes a lot. BTW: A lot means a couple of times per day. And yes, the cores we get (using a core dump server), are all like this (some pointed to bugs in the NKE in the past, but these could be fixed, then also SCTP.kext was explicitly mentioned in the paniclog). Any idea how to narrow down the problem? If the EIP values in the "paniclog" register dump are identical/ similar across all the crashes you've observed (note that "unresolved kernel trap" is just a generic label), and only occur when your driver is loaded, it's likely to be memory corruption as I noted previously. Is it always an EBP based access (typically a local or parameter) in idle_thread() that's causing the fault? The loop in idle_thread() briefly enables interrupts and disables them, so if you have an interrupt filter routine (that executes at interrupt context) that could be another point where corruption could occur (in addition to the the saved context at the base of the thread's kernel stack I mentioned previously--corruption of the register context below the interrupt stack frame that contains the saved value of the EBP register, for instance). Unfortunately, there's no single magic bullet when it comes to identifying sources of memory corruption of this type--determining the patterns and location of corruption and binary search via logging/tracing is one approach (after carefully walking through your code to look for erroneous stores to memory, bad DMA bounds, stack overflows etc.; I don't think page protection/debug register type schemes to trap the bad store (assuming it's not a physical mode store) would be useful here since the register context would be very frequently accessed. Logic analyzers (very expensive) would be a last resort). The kernel trace facility (/usr/local/bin/trace - h) can tell you what events (such as interrupts and context switches) occurred on that processor, but given that it panics, you'd probably have to examine the trace buffer in memory (see xnu/ bsd/kern/kdebug.c in the kernel sources for the internals of the trace facility) to extract the last few trace events. Derek We now had the same crash on a XServe dual G5 which looks like the one below. We think to have spotted the real culprit in the meantime but its like fishing in the dark and wild guessing and hoping to have it fixed. But as we see several crashdumps a day from different machines, we will know pretty soon if we found it or not. But we want to be sure ;-). So is there anything useable we can follow on this gdb output which could give us some hints? As iPhone is there, having SCTP under MacOS X is even more a necessarity and this NKE is the one closed to production quality with the exception of one single very nasty bug we are tracking down. Then we are off to do the same under Leopard. (oh by the way, where can we checkout the sources of current leopard beta so we can verify our design?). -----SNIP---- xg5:/Users/afink root# gdb -c core-xnu-792-85.195.192.42-b7c6afb3-GOOD GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:54:33 GMT 2006) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin". unable to read unknown load command 0x7a000000 #0 0x00000000 in ?? () (gdb) source KernelDebugKit/kgmacros KernelDebugKit/kgmacros:26: Error in sourced command file: No symbol table is loaded. Use the "file" command. (gdb) symbol-file KernelDebugKit/mach_kernel Reading symbols from /Users/afink/KernelDebugKit/mach_kernel...done. (gdb) source KernelDebugKit/kgmacros Cannot access memory at address 0x0 Cannot access memory at address 0x0 Loading Kernel GDB Macros package. Type "help kgm" for more info. (gdb) add-symbol-file org.sctp.nke.sctp.sym-GOOD add symbol table from file "org.sctp.nke.sctp.sym-GOOD"? (y or n) y Reading symbols from /Users/afink/org.sctp.nke.sctp.sym-GOOD...done. (gdb) paniclog Cannot access memory at address 0x0 Cannot access memory at address 0x0 Unresolved kernel trap(cpu 1): 0x400 - Inst access DAR=0x0000000003D67000 PC=0x0000000000000000 Latest crash info for cpu 1: Exception state (sv=0x44BC6A00) PC=0x00000000; MSR=0x40001030; DAR=0x03D67000; DSISR=0x40000000; LR=0x00000000; R1=0x2CA73DE0; XCP=0x00000010 (0x400 - Inst access) Backtrace: 0x0379AA8C 0x00023900 0x000ABAAC 0x00000000 backtrace terminated - frame not mapped or invalid: 0xBFFF70A0 Proceeding back via exception chain: Exception state (sv=0x44BC6A00) previously dumped as "Latest" state. skipping... Exception state (sv=0x44AB0280) PC=0x9004A3B8; MSR=0x0000F030; DAR=0x03D67000; DSISR=0x42000000; LR=0x9004A2FC; R1=0xBFFF70A0; XCP=0x00000030 (0xC00 - System call) Kernel version: Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC panic(cpu 0 caller 0xFFFF0004): wait queue deadlock - wq=0x2e4e900, cpu=0 Latest stack backtrace for cpu 0: Backtrace: 0x00095138 0x00095650 0x00026898 0x0003EF98 0x00022CC0 0x000ABAAC 0x00000000 Proceeding back via exception chain: Exception state (sv=0x44C11780) PC=0x9000AB48; MSR=0x0000D030; DAR=0x03D63000; DSISR=0x42000000; LR=0x9000AA9C; R1=0xBFFFEC00; XCP=0x00000030 (0xC00 - System call) Kernel version: Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC (gdb) (gdb) list *0x000ABAAC No source file for address 0xabaac. (gdb) list *0x0379AA8C No source file for address 0x379aa8c. (gdb) list *0x00023900 0x23900 is in mach_msg_overwrite_trap (/SourceCache/xnu/xnu-792.12.6/ osfmk/ipc/mach_msg.c:1862). 1857 in /SourceCache/xnu/xnu-792.12.6/osfmk/ipc/mach_msg.c (gdb) list *0x000ABAAC No source file for address 0xabaac. (gdb) (gdb) list *0x00095138 0x95138 is in print_backtrace (/SourceCache/xnu/xnu-792.12.6/osfmk/ ppc/model_dep.c:403). 398 /SourceCache/xnu/xnu-792.12.6/osfmk/ppc/model_dep.c: No such file or directory. in /SourceCache/xnu/xnu-792.12.6/osfmk/ppc/model_dep.c (gdb) list *0x00095650 0x95650 is in Debugger (/SourceCache/xnu/xnu-792.12.6/osfmk/ppc/ model_dep.c:557). 552 in /SourceCache/xnu/xnu-792.12.6/osfmk/ppc/model_dep.c (gdb) list *0x00026898 0x26898 is in panic (/SourceCache/xnu/xnu-792.12.6/osfmk/kern/debug.c: 206). 201 /SourceCache/xnu/xnu-792.12.6/osfmk/kern/debug.c: No such file or directory. in /SourceCache/xnu/xnu-792.12.6/osfmk/kern/debug.c (gdb) list *0x0003EF98 0x3ef98 is in wait_queue_peek64_locked (/SourceCache/xnu/xnu-792.12.6/ osfmk/kern/wait_queue.c:1284). 1279 /SourceCache/xnu/xnu-792.12.6/osfmk/kern/wait_queue.c: No such file or directory. in /SourceCache/xnu/xnu-792.12.6/osfmk/kern/wait_queue.c (gdb) list *0x00022CC0 0x22cc0 is in mach_msg_overwrite_trap (/SourceCache/xnu/xnu-792.12.6/ osfmk/ipc/mach_msg.c:1110). 1105 /SourceCache/xnu/xnu-792.12.6/osfmk/ipc/mach_msg.c: No such file or directory. in /SourceCache/xnu/xnu-792.12.6/osfmk/ipc/mach_msg.c (gdb) list *0x000ABAAC No source file for address 0xabaac. (gdb) This email sent to site_archiver(a)lists.apple.com

1 0

Re: TCP, and clamping MSS..?
by Vincent Lubet 10 Jan '07

10 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Andrew, Thanks, Vincent On Jan 10, 2007, at 1:50 PM, Andrew Gallatin wrote: /* * Determine a reasonable value for maxseg size. * If the route is known, check route for mtu. * If none, use an mss that can be handled on the outgoing * interface without forcing IP to fragment; if bigger than * an mbuf cluster (MCLBYTES), round down to nearest multiple of MCLBYTES * to utilize large mbufs. If no route is found, route has no mtu, <....> And in tcp_mss() FreeBSD actually does this: tp->t_maxseg = mss; #if (MCLBYTES & (MCLBYTES - 1)) == 0 if (mss > MCLBYTES) mss &= ~(MCLBYTES-1); #else if (mss > MCLBYTES) mss = mss / MCLBYTES * MCLBYTES; #endif tp->t_maxseg = mss; Any idea why this code is missing from darwin? While trying to get decent 10GbE jumbo frame performance numbers from MacOSX 10.4.8 between a pair of 2.6Ghz Mac Pros, I found I was limited to about 7Gb/s for a single threaded test, or 8.8Gb/s for a multi-threaded test. If I manually set the MTU such that the MSS winds up as 8192, then the single threaded performance jumps to 8Gb/s and the multi-threaded to 9.08Gb/s. Eg: % netperf242 -H macpro01-m -l10 -P 0 524288 524288 524288 10.00 7047.07 % sudo route change -mtu 8244 macpro01-m change host macpro01-m % netperf242 -H macpro01-m -l10 -P 0 524288 524288 524288 10.00 8009.17 (I'm quoting a small sample size for this email, but it is reproducable over a large number of runs..) _______________________________________________ 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 is an optimization that is simple missin in xnu -- thanks for bringing it to our attention. Feel free to file an enhancement request at http:// bugreporter.apple.com/ to make sure this won't fall through the cracks. Most BSDs "clamp" the MSS to a multiple of MCLBYTES. >From netinet/tcp_input.c in both darwin and and FreeBSD: Drew This email sent to site_archiver(a)lists.apple.com

1 0

TCP, and clamping MSS..?
by Andrew Gallatin 10 Jan '07

10 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Most BSDs "clamp" the MSS to a multiple of MCLBYTES. >From netinet/tcp_input.c in both darwin and and FreeBSD: /* * Determine a reasonable value for maxseg size. * If the route is known, check route for mtu. * If none, use an mss that can be handled on the outgoing * interface without forcing IP to fragment; if bigger than * an mbuf cluster (MCLBYTES), round down to nearest multiple of MCLBYTES * to utilize large mbufs. If no route is found, route has no mtu, <....> And in tcp_mss() FreeBSD actually does this: tp->t_maxseg = mss; #if (MCLBYTES & (MCLBYTES - 1)) == 0 if (mss > MCLBYTES) mss &= ~(MCLBYTES-1); #else if (mss > MCLBYTES) mss = mss / MCLBYTES * MCLBYTES; #endif tp->t_maxseg = mss; Any idea why this code is missing from darwin? While trying to get decent 10GbE jumbo frame performance numbers from MacOSX 10.4.8 between a pair of 2.6Ghz Mac Pros, I found I was limited to about 7Gb/s for a single threaded test, or 8.8Gb/s for a multi-threaded test. If I manually set the MTU such that the MSS winds up as 8192, then the single threaded performance jumps to 8Gb/s and the multi-threaded to 9.08Gb/s. Eg: % netperf242 -H macpro01-m -l10 -P 0 524288 524288 524288 10.00 7047.07 % sudo route change -mtu 8244 macpro01-m change host macpro01-m % netperf242 -H macpro01-m -l10 -P 0 524288 524288 524288 10.00 8009.17 (I'm quoting a small sample size for this email, but it is reproducable over a large number of runs..) Drew _______________________________________________ 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

ifnet_output_raw() causes crash on Mac PowerBook G4
by Alexander Klyuev 10 Jan '07

10 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Organization: MusicLab, Inc. Hi All, Does anybody know what is reason of this strange issue? Thank you, Alexander _______________________________________________ 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.… Call to ifnet_output_raw(...) (in order to output mbuf with built-in data) causes crash (0x300 Data access) on Mac PowerBook G4 when ifnet_t argument references to AppleAirPort (kext ver 3.4.8) network interface (Darwin Kernel ver 8.8.0). However it never happens when network interface is not AirPort or Mac is not PowerBook G4. This email sent to site_archiver(a)lists.apple.com

1 0

Re: User-space to kernel communication
by Michael Smith 10 Jan '07

10 Jan '07

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jan 9, 2007, at 7:40 PM, Greg wrote: On Jan 9, 2007, at 8:32 PM, Michael Smith wrote: typedef struct { unsigned char buffer[256]; unsigned char bufferSize; } MyIOUserClientArg; = Mike _______________________________________________ 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.… Also, as I asked in the other email, can you pass a pointer to a user-land allocated buffer as a parameter to a method call for the kernel to use? You can, although the kernel can't access it directly. As I pointed out previously, if the data is small (you mentioned 50 bytes, which is very small) you're better off just copying it. If you need to pass it to hardware, or to map it, you need to construct an IOMemoryDescriptor referencing it. By "just copying it" do you mean, as Brian pointed out, passing a structure of this sort: Yes, although I would put the size member at the front of the structure so that you don't waste another cache line accessing it. This email sent to site_archiver(a)lists.apple.com

1 0