November 2002 - Darwin-kernel

Can't attach using 2 Machine Debugging
by Michael Cashwell 15 Nov '02

15 Nov '02

Greeting, I've been having fits trying to get gdb to work in a 2 machine setup so I can interactively debug my KNE. I've read all the docs I can find (tn2063 and Hello Debugger [revved on 1Nov!]) but am still getting nowhere. I'm running "6.2 Darwin Kernel Version 6.2: Tue Nov 5 22:00:03 PST 2002; root:xnu/xnu-344.12.2.obj~1/RELEASE_PPC" on both a Tibook (dev) and a Pismo G3 (target). I've done the incantations to get the permanent arp entry and using file sharing copied the .sym file from kextload -s to the dev system and have set the boot-args to "debug=0xe". On the dev system I have: [Mikes-Tibook:~] cashwell% sudo arp -s 10.0.0.10 0:3:93:3:4b:92 [Mikes-Tibook:~] cashwell% arp -a ? (10.0.0.10) at 0:3:93:3:4b:92 permanent ? (224.0.0.251) at 1:0:5e:0:0:fb permanent ? (239.255.255.253) at 1:0:5e:7f:ff:fd permanent I then trigger the panic on the target. It spews text on the screen ending with the correct MAC and IP addresses and claims to be waiting for a remote debugger connection. Nothing else ever happens on the target's display. I then do the normal: [Mikes-Tibook:~] cashwell% gdb /mach_kernel ... (gdb) add-symbol-file com.company.kext.myshim.sym add symbol table from file "com. company.kext.myshim.sym" at (y or n) y Reading symbols from /Users/cashwell/com.company.kext.myshim.sym...done. (gdb) target remote-kdp (gdb) attach 10.0.0.10 and then get 10 repetitions of error messages: kdp_reply_wait: error from kdp_receive: receive timeout exceeded kdp_transaction (remote_connect): transation timed out kdp_transaction (remote_connect): re-sending transaction and kdp_transaction (remote_connect): host not responding; will retry unable to connect to host "10.0.0.10": receive timeout exceeded If I try it with a non-existent IP address it ends slightly differently: kdp_transmit_fd: sendto returns -1: Host is down (64) unable to connect to host "10.0.0.44": RR_IP_ERROR so it looks like the permanent route is having some effect. This is the first time I've needed to do 2 machine debugging for a very long time and I did just update to 10.2.2. Can anyone confirm that it still works? I saw a worrisome comment in an Apple doc for the meaning of the boot-arg flags. It says debug flag 0x10 is to "Make ddb (kdb) the default debugger (requires a custom kernel)." I don't have that flag set as the docs say to use 0xe. Yet the gdb command the docs say to use is "target remote-kdb". Which is right? One last datum, my target machine does have 2 ethernet interfaces active (one wired and one Airport). I need the latter so an app running on another platform can trigger the panic. But I'm using the wired interface for debugging (or trying to). Could having both enabled be messing things up even thought the panic spew lists the addresses of the wired interface? Wondering if it was the Pismo's Ethernet hardware I tried another TiBook as the target machine but it acted identically. Any ideas would be appreciated. Thanks, Mike _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

RE: Open and read a file in kernel space
by Torsten Gatu 14 Nov '02

14 Nov '02

I had the same problem and I gave up on it. At that time (couple of months ago) there was no good solution to this problem. You can find discussions about this in the list archives, either this list or the 'drivers' list. /TG -----Original Message----- From: Gerhard Ahuis [mailto:darwin-kernel@ats.xs4all.nl] Sent: den 11 november 2002 23:42 To: darwin-kernel(a)lists.apple.com Subject: Open and read a file in kernel space Hi All, How can I open and read a file from the local filesystem in the kernel space from Darwin ? I need to do this in a driver. Best regards, Gerhard. -- Gerhard Ahuis pe1rlz(a)amsat.org Unsolicited advertisements subject to $1000 consulting fee. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Performance problems under 10.2
by Tim Seufert 13 Nov '02

13 Nov '02

On Wednesday, November 13, 2002, at 09:13 AM, Tyler Ward wrote: There are a few things to be noticed here. First of all, it's performing lots of superfluous opening and closing of "outfile.sah". But by lots, that's only one a second or so, completely insignificant. In fact, there are large time periods (up to two seconds) where the program isn't making any syscalls. Consequently it is pretty clear that syscalls aren't the cause of this. While this was running it was still using 35% or more systime, though it was tracing. I'm ktracing setiathome at this very moment, and typically systime (as reported by top) is 2% or less. It never goes much higher than that unless I start doing other things that would be expected to spike system time. (open a Terminal window, etc.) One thing that could be a problem is this..... PID COMMAND %CPU TIME FAULTS ... BSDSYSCAL ... CSWITCH 5169 top 0.6% 0:00.55 2075 22527 419 5168 setiathome 56.4% 1:01.51 13954 17563 29892 OK, I've dropped fields that I don't think are important (generally very low numbers). This is setiathome after running for only a few seconds, maybe 10 or 20. Notice that it's had 13,000 faults and almost 30,000 context switches. This is running at nice = 20. On my system setiathome is getting 200 to 500 faults per second and 10 to 20 context switches per second (judging by top in delta mode). After four minutes of CPU time (maybe 5 minutes of real time) it looks like this... 5168 setiathome 71.0% 4:04.97 45376 .... 68898 .... 113043 Once again with the same fields dropped. Notice that it's had 45,000 faults, 70,000 syscalls, and 113,000 CSwitches. Here, I get: PID COMMAND %CPU TIME FAULTS ... BSDSYSCALL MACHSYSCALL CSWITCH 688 setiathome 98.9% 4:04.61 85313 ... 5322 1279 7006 Nearly double the faults, but 1/13 as many system calls (assuming you recorded BSD syscalls) and 1/16 the context switches. Now one last bit of information. Here's the top header, not in event mode. Processes: 51 total, 4 running, 47 sleeping... 145 threads 12:02:25 Load Avg: 1.65, 1.44, 1.36 CPU usage: 75.5% user, 24.5% sys, 0.0% idle SharedLibs: num = 42, resident = 16.2M code, 1.40M data, 5.38M LinkEdit MemRegions: num = 3759, resident = 84.4M + 5.05M private, 62.0M shared PhysMem: 41.5M wired, 108M active, 205M inactive, 354M used, 93.5M free VM: 1.37G + 34.0M 15734(0) pageins, 14783(0) pageouts The same: Processes: 50 total, 3 running, 47 sleeping... 152 threads 14:31:02 Load Avg: 1.14, 1.06, 1.00 CPU usage: 51.2% user, 4.2% sys, 44.7% idle SharedLibs: num = 82, resident = 23.3M code, 2.38M data, 5.96M LinkEdit MemRegions: num = 4196, resident = 76.1M + 7.11M private, 114M shared PhysMem: 67.4M wired, 89.9M active, 218M inactive, 376M used, 648M free VM: 2.25G + 49.8M 7966(0) pageins, 0(0) pageouts Note that the 44.7% idle percentage is due to the fact that this is a SMP machine and setiathome is single threaded. What does this tell us? Well first of all, there's no shortage of ram, so there's no reason why seti should be having many faults. Not true. You can, for example, have lots of faults due to memory allocation. When a process asks for memory, the OS claims to give it some but is really only giving it virtual address space. Physical pages aren't allocated until the process tries to touch some of the allocated address space and faults. I believe Mach IPC also uses VM tricks, which may be another source of page faults that aren't actually swapfile use. The page faults are probably the cause of the context switches, and together they're probably the cause of much of the system time. Just a guess. On this system, I got more faults and dramatically fewer context switches. This would tend to rule out faults in and of themselves as the cause of excessive context switches. However, swapfile use certainly could cause extra context switches (since a process waiting for a pagein is blocked), and you are getting a lot of that. The other interesting thing is that there are 70,000 syscalls in the listing, but not nearly that many in the ktrace. ktrace didn't pick up more than say ten syscalls per second, meaning that after 5 minutes there should have been no more than 3,000 syscalls, plus whatever happened while starting the program. So... 70,000 - 18,000 - 3,000 = 49,000 syscalls unaccounted for. So, it looks to me like the performance problem comes from two places. The extra syscalls, and the completely unnecessary page faults. I might even go as far as to say that fixing both of these might give all programs a significant boost across the board. I don't know why you have so many syscalls, but that and the actual swapfile access are where I'd focus my attention. If you can, scrounge up some extra memory and retest. You may find that this is really just a matter of running out of physical RAM at some point in time, forcing the system to swap some stuff out. (roughly 57 megabytes cumulative since turning the system on, going by your pageout count) Another thing to try, if you can, is to do a fresh install of 10.2 on another disk and see how it behaves. (i.e., the "maybe there is something misconfigured somewhere" theory) _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Building Darwin kernel on top of Jaguar
by Rob McKeever 13 Nov '02

13 Nov '02

Now I feel like a fool... just tried copying the kernel over again, double-checked the permissions and ownership (both were OK), and rebooted. Worked like a charm. Still wondering why it didn't work last night, though. Thanks. -Rob McKeever robm(a)mac.com On Wednesday, November 13, 2002, at 11:04 AM, Louis Gerbarg wrote: It should work. What are the permissions on the mach_kernel you write out. BootX is picky about that. It has to be root owned and not group or world writeable. Louis On Wednesday, November 13, 2002, at 12:30 AM, Rob McKeever wrote: Is it possible yet to (re)build the darwin kernel using OS X 10.2.x (Jaguar) and the publicly available tools? I've tried using the ToT tools from the CVS archives and the instructions for rebuilding kernels under 10.1 as a starting point, but each attempt has ended with BootX unable to locate a valid kernel file and displaying the dreaded circle with a slash graphic. Unfortunately, I was kinda hoping to test some stuff that would require having a kernel with debugging symbols in it. -Rob McKeever robm(a)mac.com -- "Quidquid latine dictum sit, altum viditur." _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. -- "Quidquid latine dictum sit, altum viditur." _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Performance problems under 10.2
by Jonas Maebe 13 Nov '02

13 Nov '02

On woensdag, nov 13, 2002, at 18:13 Europe/Brussels, Tyler Ward wrote: What does this tell us? Well first of all, there's no shortage of ram, so there's no reason why seti should be having many faults. The page faults are probably the cause of the context switches, and together they're probably the cause of much of the system time. I would guess it's simply reading data (doesn't seti use quite big datafiles?). Remember that a page is only 4kb and you said 49,000 were unaccounted for. That's about 2MB of data. Since dnetc is also getting a lot of context switches but no page faults, I don't think that's the problem. FWIW, the ktrace/kdump of dnetc shows: 471 dnetc CALL gettimeofday(0xf0080d20,0) 471 dnetc RET gettimeofday 1037184384/0x3dd22d80 471 dnetc CALL __sysctl(0xf0080d30,0x2,0xf0080d10,0xf0080d38,0,0) 471 dnetc RET __sysctl 0 471 dnetc CALL gettimeofday(0xf0080d10,0) 471 dnetc RET gettimeofday 1037184384/0x3dd22d80 471 dnetc CALL __sysctl(0xf0080d20,0x2,0xf0080d00,0xf0080d28,0,0) 471 dnetc RET __sysctl 0 ... I don't have a clue why it's calling that syscall so often though (then again, it already did that under 10.1.5 as well I guess, since I didn't upgrade the client since then). Jonas _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Building Darwin kernel on top of Jaguar
by Louis Gerbarg 13 Nov '02

13 Nov '02

It should work. What are the permissions on the mach_kernel you write out. BootX is picky about that. It has to be root owned and not group or world writeable. Louis On Wednesday, November 13, 2002, at 12:30 AM, Rob McKeever wrote: Is it possible yet to (re)build the darwin kernel using OS X 10.2.x (Jaguar) and the publicly available tools? I've tried using the ToT tools from the CVS archives and the instructions for rebuilding kernels under 10.1 as a starting point, but each attempt has ended with BootX unable to locate a valid kernel file and displaying the dreaded circle with a slash graphic. Unfortunately, I was kinda hoping to test some stuff that would require having a kernel with debugging symbols in it. -Rob McKeever robm(a)mac.com -- "Quidquid latine dictum sit, altum viditur." _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Performance problems under 10.2
by Tyler Ward 13 Nov '02

13 Nov '02

First of all, I don't think the fact that it runs at nice 20 is a problem. I generally run seti reniced to 20, but even without renicing the effect is the same. OK, first I searched for this...... " (This is the last message displayed while the client works. To see progress messages between now and completion of processing, operate the client with the -verbose option. You can also see the progress of the client by looking at the 'prog=' line in the state.sah file. " That's very near the end of the ktrace file. Everything after that is just general operation, not startup or anything. I ran the program for about 10 seconds or so, and only 2% of the ktrace file is after the startup message. This came from "kdump -t cnisw -R" This is a representative sample from that area..... 5132 setiathome 0.000121 RET read 2271/0x8df 5132 setiathome 0.000052 CALL close(0x4) 5132 setiathome 0.000056 RET close 0 5132 setiathome 1.813266 CALL open(0xbffff768,0,0x1b6) 5132 setiathome 0.000198 NAMI "outfile.sah" 5132 setiathome 0.000094 RET open 4 5132 setiathome 0.000082 CALL fstat(0x4,0xbffff590) 5132 setiathome 0.000058 RET fstat 0 5132 setiathome 0.000063 CALL fstat(0x4,0xbffff6a0) 5132 setiathome 0.000051 RET fstat 0 5132 setiathome 0.000050 CALL lseek(0x4,0,0,0x1) 5132 setiathome 0.000049 RET lseek 0 5132 setiathome 0.000050 CALL lseek(0x4,0,0,0) 5132 setiathome 0.000103 RET lseek 0 5132 setiathome 0.000060 CALL read(0x4,0x78050,0x1000) 5132 setiathome 0.000099 GIO fd 4 read 2271 bytes ..... 5132 setiathome 0.000147 RET read 2271/0x8df 5132 setiathome 0.000056 CALL close(0x4) 5132 setiathome 0.000068 RET close 0 5132 setiathome 0.000062 CALL getrusage(0,0xbffff768) 5132 setiathome 0.000060 RET getrusage 0 5132 setiathome 0.001635 CALL open(0xbffff718,0,0x1b6) 5132 setiathome 0.000079 NAMI "outfile.sah" 5132 setiathome 0.000064 RET open 4 5132 setiathome 0.000057 CALL fstat(0x4,0xbffff540) 5132 setiathome 0.000052 RET fstat 0 5132 setiathome 0.002187 CALL fstat(0x4,0xbffff650) 5132 setiathome 0.000099 RET fstat 0 5132 setiathome 0.000052 CALL lseek(0x4,0,0,0x1) 5132 setiathome 0.000048 RET lseek 0 5132 setiathome 0.000051 CALL lseek(0x4,0,0,0) 5132 setiathome 0.000047 RET lseek 0 5132 setiathome 0.000050 CALL read(0x4,0x78050,0x1000) 5132 setiathome 0.000078 GIO fd 4 read 2271 bytes ...... 5132 setiathome 0.000092 RET read 2271/0x8df 5132 setiathome 0.000053 CALL close(0x4) 5132 setiathome 0.000058 RET close 0 5132 setiathome 1.906561 CALL open(0xbffff768,0,0x1b6) 5132 setiathome 0.000205 NAMI "outfile.sah" 5132 setiathome 0.000092 RET open 4 5132 setiathome 0.000118 CALL fstat(0x4,0xbffff590) 5132 setiathome 0.000059 RET fstat 0 5132 setiathome 0.000063 CALL fstat(0x4,0xbffff6a0) 5132 setiathome 0.000053 RET fstat 0 5132 setiathome 0.000052 CALL lseek(0x4,0,0,0x1) 5132 setiathome 0.000050 RET lseek 0 5132 setiathome 0.000052 CALL lseek(0x4,0,0,0) 5132 setiathome 0.000049 RET lseek 0 5132 setiathome 0.000053 CALL read(0x4,0x78050,0x1000) 5132 setiathome 0.000099 GIO fd 4 read 2271 bytes There are a few things to be noticed here. First of all, it's performing lots of superfluous opening and closing of "outfile.sah". But by lots, that's only one a second or so, completely insignificant. In fact, there are large time periods (up to two seconds) where the program isn't making any syscalls. Consequently it is pretty clear that syscalls aren't the cause of this. While this was running it was still using 35% or more systime, though it was tracing. One thing that could be a problem is this..... PID COMMAND %CPU TIME FAULTS ... BSDSYSCAL ... CSWITCH 5169 top 0.6% 0:00.55 2075 22527 419 5168 setiathome 56.4% 1:01.51 13954 17563 29892 OK, I've dropped fields that I don't think are important (generally very low numbers). This is setiathome after running for only a few seconds, maybe 10 or 20. Notice that it's had 13,000 faults and almost 30,000 context switches. This is running at nice = 20. After four minutes of CPU time (maybe 5 minutes of real time) it looks like this... 5168 setiathome 71.0% 4:04.97 45376 .... 68898 .... 113043 Once again with the same fields dropped. Notice that it's had 45,000 faults, 70,000 syscalls, and 113,000 CSwitches. Now one last bit of information. Here's the top header, not in event mode. Processes: 51 total, 4 running, 47 sleeping... 145 threads 12:02:25 Load Avg: 1.65, 1.44, 1.36 CPU usage: 75.5% user, 24.5% sys, 0.0% idle SharedLibs: num = 42, resident = 16.2M code, 1.40M data, 5.38M LinkEdit MemRegions: num = 3759, resident = 84.4M + 5.05M private, 62.0M shared PhysMem: 41.5M wired, 108M active, 205M inactive, 354M used, 93.5M free VM: 1.37G + 34.0M 15734(0) pageins, 14783(0) pageouts What does this tell us? Well first of all, there's no shortage of ram, so there's no reason why seti should be having many faults. The page faults are probably the cause of the context switches, and together they're probably the cause of much of the system time. Just a guess. The other interesting thing is that there are 70,000 syscalls in the listing, but not nearly that many in the ktrace. ktrace didn't pick up more than say ten syscalls per second, meaning that after 5 minutes there should have been no more than 3,000 syscalls, plus whatever happened while starting the program. So... 70,000 - 18,000 - 3,000 = 49,000 syscalls unaccounted for. So, it looks to me like the performance problem comes from two places. The extra syscalls, and the completely unnecessary page faults. I might even go as far as to say that fixing both of these might give all programs a significant boost across the board. Tyler Ward tjw19(a)columbia.edu _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Building Darwin kernel on top of Jaguar
by Rob McKeever 13 Nov '02

13 Nov '02

Is it possible yet to (re)build the darwin kernel using OS X 10.2.x (Jaguar) and the publicly available tools? I've tried using the ToT tools from the CVS archives and the instructions for rebuilding kernels under 10.1 as a starting point, but each attempt has ended with BootX unable to locate a valid kernel file and displaying the dreaded circle with a slash graphic. Unfortunately, I was kinda hoping to test some stuff that would require having a kernel with debugging symbols in it. -Rob McKeever robm(a)mac.com -- "Quidquid latine dictum sit, altum viditur." _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Re: Bug fix for kern_control.c
by Vincent Lubet 13 Nov '02

13 Nov '02

Michael, The best way to get this fixed ASAP is for you to file a problem report to https://bugreport.apple.com and/or to contact your DTS representative. Vincent Lubet On Tuesday, November 12, 2002, at 12:09 PM, Michael Cashwell wrote: Greetings all, After some digging today I've found a bug in an error handling case for connections to AF_SYSTEM / SYSPROTO_CONTROL sockets when the kernel code (an NKE in my case) registers its handlers using ctl_flags CTL_FLAG_PRIVILEGED. If a connect() attempt is made without uid 0 (ie: one forgets to use sudo), it fails correctly with an EPERM error. But the control socket is left in an inconsistent state such that all further attempts to connect to it will fail with an EBUSY error. This is true even if the socket that failed to connect is closed. The only way to recover is to have the NKE deregister and then reregister its handlers for that signature and unit number (which for me is the same as having to unload and reload my kext). The bug is in xnu/bsd/kern_control.c, in ctl_connect() where (around line 177) it does ctl->skt = so before checking for an EPERM error and leaves it set even if an error occurs. ctl_disconnect() contributes to the problem by doing nothing if so->so_pcb is NULL which it will be if the EPERM error occurred (since the connect failed). Once this happens, all future ctl_connect() calls fail with EBUSY since ctl->skt has a value and ctl_disconnect() calls do nothing. Several fixes come to mind. I think the cleanest would be to move the assignment of ctl->skt = so down after line 184 (after the CTL_FLAG_PRIVILEGED test). As long as suser() has no memory alias to ctl->skt (which would be very ugly!) this would fix it. Next best would be to clear ctl->skt in the two error returns in the CTL_FLAG_PRIVILEGED block as is done if the registered connect() function a few lines later returns an error. (That must be done that way since that function clearly has access to ctl and hence may rightly expect ctl->skt to be set. I wouldn't think that suser() would need that and therefore setting ctl->skt so early is dubious.) Lastly, the NULLing of ctl->skt in ctl_disconnect() could be pulled out of the test of so->so_pcb so it's always cleared regardless of the connected state. I think this is poor as it muddles the meaning of a non-NULL ctl->skt but it would avoid this particular problem. If I've missed something or if there is a more formal way to submit these sorts of fixes please let me know. - Mike _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0

Bug fix for kern_control.c
by Michael Cashwell 12 Nov '02

12 Nov '02

Greetings all, After some digging today I've found a bug in an error handling case for connections to AF_SYSTEM / SYSPROTO_CONTROL sockets when the kernel code (an NKE in my case) registers its handlers using ctl_flags CTL_FLAG_PRIVILEGED. If a connect() attempt is made without uid 0 (ie: one forgets to use sudo), it fails correctly with an EPERM error. But the control socket is left in an inconsistent state such that all further attempts to connect to it will fail with an EBUSY error. This is true even if the socket that failed to connect is closed. The only way to recover is to have the NKE deregister and then reregister its handlers for that signature and unit number (which for me is the same as having to unload and reload my kext). The bug is in xnu/bsd/kern_control.c, in ctl_connect() where (around line 177) it does ctl->skt = so before checking for an EPERM error and leaves it set even if an error occurs. ctl_disconnect() contributes to the problem by doing nothing if so->so_pcb is NULL which it will be if the EPERM error occurred (since the connect failed). Once this happens, all future ctl_connect() calls fail with EBUSY since ctl->skt has a value and ctl_disconnect() calls do nothing. Several fixes come to mind. I think the cleanest would be to move the assignment of ctl->skt = so down after line 184 (after the CTL_FLAG_PRIVILEGED test). As long as suser() has no memory alias to ctl->skt (which would be very ugly!) this would fix it. Next best would be to clear ctl->skt in the two error returns in the CTL_FLAG_PRIVILEGED block as is done if the registered connect() function a few lines later returns an error. (That must be done that way since that function clearly has access to ctl and hence may rightly expect ctl->skt to be set. I wouldn't think that suser() would need that and therefore setting ctl->skt so early is dubious.) Lastly, the NULLing of ctl->skt in ctl_disconnect() could be pulled out of the test of so->so_pcb so it's always cleared regardless of the connected state. I think this is poor as it muddles the meaning of a non-NULL ctl->skt but it would avoid this particular problem. If I've missed something or if there is a more formal way to submit these sorts of fixes please let me know. - Mike _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.

1 0