December 2006 - Darwin-kernel

Re: waiting queue
by Quinn 06 Dec '06

06 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware Here's the sequence of events when you use THREAD_UNINT. 2. Thread A now blocks uninterruptibly using IOCommandGate::commandSleep. 3. Much time passes. 6. As above. 7. As above (thread B blocks in vm_map_remove). 13. Thread B now runs its AST and cleans itself up (thread_terminate_self). _______________________________________________ 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:11 -0800 5/12/06, Michael Smith wrote: As a general rule, if you believe that your hardware is reliable, use THREAD_UNINT to be safe. There's one gotcha here. Because of the way user clients are implementation, you shouldn't use THREAD_UNINT while blocking in a user client if that user client has wired down any memory from the client process. If you do so, there will be no way to kill the task. I've included the gory details below. This was on 10.3.x, so YMMV on later systems. If you look at task_terminate_internal, you'll see that midway through its implementation it calls thread_terminate_internal for each thread in the task. This doesn't actually terminate the threads. Rather, it schedules an AST for the thread. The AST is like a secondary interrupt. The next time the thread leaves the kernel, it will run the AST handler before it leaves. This includes two special cases: o If the thread is currently running on another CPU, it will send a inter-CPU interrupt to force the AST to happen promptly. o If the thread is blocked, it will be woken up so that it can leave the kernel and run the AST. Remember that the thread executing task_terminate_internal could be part of the task, and thus is subject to this AST scheduling. However, because that thread is still running inside the kernel, scheduling an AST on the thread has no immediate impact. The AST only runs as the thread leaves the kernel. task_terminate_internal continues to run and eventually calls ipc_space_destroy and vm_map_remove. Ultimately task_terminate_internal returns and the thread winds its way out of the kernel. As it leaves the kernel the thread executes any pending ASTs. If this thread is part of the terminated task, it will execute the AST that was scheduled when task_terminate_internal called thread_terminate_internal. The AST handler for task termination does the key work via a call to thread_terminate_self (osfmk/kern/thread.c). So, as task_terminate_internal has been doing its thread, other threads in the task have been running, entering the kernel, and executing the thread_terminate_self routine as they leave. thread_terminate_self decrements the count of the number of running threads in the task and, if it hits 0, calls BSD (the proc_exit routine) to clean up BSD constructs associated with the task. It then goes on to clean up various aspects of the thread, mark the thread as terminated (by setting TH_TERMINATE), and then blocks the thread (by calling thread_block). When the thread switcher switches away from a terminated thread, it schedules the thread to be reaped (thread_reaper_enqueue) which, in turn, wakes up the reaper thread (reaper_thread_continue) which finally disposes of the thread's data structures. Given the above background, it's now possible to show how your code gets into trouble, and why moving away from THREAD_UNINT fixes it. 1. The blocking thread (thread A) enters your user client. As it enters the kernel it increments the number of send rights for the user client's port. 4. One of other the threads in the task (thread B) decides to that it's time to die (it's the target of the force quit signal, or it calls "exit", or it bus errors, or whatever). This results in a call to task_terminate_internal. 5. task_terminate_internal calls thread_terminate_internal for each thread in the task, which schedules an AST for those threads, including threads A and B. Thread A is blocked uninterruptably, and so it does nothing in response to this AST request. Thread B is still inside the kernel (running task_terminate_internal itself) and so does not respond immediately to the AST. 6. Thread B, still running task_terminate_internal, now calls ipc_space_destroy. This destroys all of the rights for the task. However, the extra send right added in step 1 prevents your user client's port's send right count going to 0, thus a "no more senders" notification isn't given, thus your ::clientDied method is not called. 7. Thread B now calls vm_map_remove. This ends up blocking because one of the VM map entries is wired by your driver. The task is now deadlocked. Thread B is blocked waiting for your driver to unwire the memory. However, that won't happen until ::clientDied is called. However, that can't happen because thread A is holding a send right for your user client's port, and thread A is blocked uninterruptibly. Now let's look at what happens if thread A blocks interruptibly. Everything proceeds as above until step 5. At that point things diverge with the following sequence. 5. task_terminate_internal calls thread_terminate_internal for each thread in the task, which schedules an AST for those threads, including threads A and B. As before, thread B is still inside the kernel (running task_terminate_internal itself) and so does not respond immediately to the AST. However, thread A is blocked in IOCommandGate::commandSleep and the AST causes it to unblock. It will eventually return from IOCommandGate::commandSleep with a THREAD_INTERRUPTED error. 8. At this point thread A is scheduled. It returns from IOCommandGate::commandSleep with a THREAD_INTERRUPTED error. Eventually this causes the thread to leave the user client and wind its way out of the kernel. As thread A runs the return path of ipc_kobject_server it decrements the send right count for the user client port. 9. Because the send right count now hits 0, a "no more senders" notification is generated for that port, which calls your ::clientDied method to be called. It's called by thread A. 10. Your ::clientDied method shuts down the user client, which in turn destroys the IOMemoryDescriptor. This unwires the VM map entry, which unblocks thread B. 11. After executing your ::clientDied method thread A eventually leaves the kernel and runs the AST which results in the thread being cleaned up (thread_terminate_self). 12. Thread B is now scheduled and returns from vm_map_remove. It continues to execute task_terminate_internal, which eventually returns and thread B leaves the kernel. As you can see, making thread A interruptible is the key point in resolving the deadlock. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Ports lost after reboot..
by sanjay yaragatti 06 Dec '06

06 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=OzJ4rmMKIaOC7fHBpYOyRX1+T3osagiqen5P0HXZ//efLgDyvXmUoZ9o8my7nhcZmMnvT9Jxen2hK4TDFVH6zEcb4z0KNkaGOUEghHkKPjFKaeLxwH7NCQ391aCDnMDQQb4eGirqBDQoNNCyyFmOz0ozEki+avG/4ePJC1IcwHQ= ; >Load your device driver again, or install it in such a fashion that it >is automatically loaded when your hardware (if any) is detected. There is no hardware.Its a driver for virtual com port. Hence cant load it automatically when the hardware is detected.. Regards, Sanjay ----- Original Message ---- From: Michael Smith <drivers(a)mu.org> To: sanjay yaragatti <sanjay_s_yaragatti(a)yahoo.co.in> Cc: darwin kernel <darwin-kernel(a)lists.apple.com> Sent: Tuesday, 5 December, 2006 4:39:25 PM Subject: Re: Ports lost after reboot.. sanjay yaragatti wrote: > Hi , > > We have registered a serial port as character device.Can see the ports in /dev directory. > But when I restart my system,the ports are lost.Is it the default behaviour? > How can i make them persistent.I mean the ports should be available even after the m/c is restarted. > Can anyone please tell me the way to do this? > Load your device driver again, or install it in such a fashion that it is automatically loaded when your hardware (if any) is detected. As Quinn notes, nodes in /dev are a side-effect of having a driver instance. = Mike __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.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

Re: waiting queue
by Michael Smith 05 Dec '06

05 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Thunderbird 1.5.0.8 (Macintosh/20061025) Dear Michael, - 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.… devmaillists wrote: thank you vey much. It helped me much. I have one question left where the documentation does not tell me the whole story: #define THREAD_UNINT 0 /* not interruptible The sleep is guaranteed to return, and only when someone explicitly wakes it up. It will return THREAD_AWAKENED. #define THREAD_INTERRUPTIBLE 1 /* may not be restartable */ The sleep is guaranteed to return, but may do so for various reasons (e.g. a signal has been sent to the thread). It will return THREAD_AWAKENED if it was woken up explicitly, and THREAD_INTERRUPTED if it was woken for some other reason. If it returns THREAD_RESTART (or anything else) you should restart the sleep. #define THREAD_ABORTSAFE 2 /* abortable safely */ The sleep is not guaranteed to return. This is a promise on your part that the thread can be aborted (destroyed) while asleep without affecting your code. Generally in the driver environment this is OK to use while you hold no locks or resources (e.g. whilst waiting to get into your driver), but otherwise you should avoid it. You are not notified when the thread is aborted; it just never comes back. As a general rule, if you believe that your hardware is reliable, use THREAD_UNINT to be safe. Only use THREAD_INTERRUPTIBLE if your device can block for an arbitrary amount of time (e.g. waiting for remote hardware that may never respond); it is primarily useful when you may be blocking a shell tool that wants to respond to control-C, or has some timeout set up. Note that if you are asleep waiting for hardware to do something, and that hardware is configured for busmaster DMA, you should use THREAD_UNINT unless you are *certain* that you can safely cancel the DMA. You must never leave pending DMA active - even if you return an I/O error, the memory that was passed to you as the destination for the I/O may be re-used immediately for something else, or in some cases it may even become invalid and cause a fatal machine check if your hardware tries to access it. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Wireless interface (ifnet_t) recognition using kpi_itrerface API?
by Shaun Wexler 05 Dec '06

05 Dec '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com On Dec 5, 2006, at 3:49 AM, Alexander Klyuev wrote: Hi ALL, Does anybody know how to distinguish wireless ethernet interface (e.g. AppleAirPort) from regular one (both are of type IFT_ETHER using ifnet_type())? _______________________________________________ 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.… Use ifnet_name() BSD name-match to get its IONetworkInterface service, then: IONetworkController *netctrl = netif->getProvider(); OSObject *bnm; bool isWireless = IFM_TYPE(netctrl->getSelectedMedium()->getType()) == IFM_IEEE80211 || ((bnm = netctrl->getProvider()->getProperty("name")) && bnm- >isEqualTo(OSSymbol::withCString("radio"))); That should match AirPort, 3rd-party 802.11* and other types of Wireless Network Adaptor. -- Shaun Wexler MacFOH http://www.macfoh.com This email sent to site_archiver(a)lists.apple.com

1 0

IOCommandgate->commandSleep meaning of the flags
by devmaillists 05 Dec '06

05 Dec '06

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

Wireless interface (ifnet_t) recognition using kpi_itrerface API?
by Alexander Klyuev 05 Dec '06

05 Dec '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com Organization: MusicLab, Inc. Hi ALL, Does anybody know how to distinguish wireless ethernet interface (e.g. AppleAirPort) from regular one (both are of type IFT_ETHER using ifnet_type())? Thanks, 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.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Ports lost after reboot..
by Michael Smith 05 Dec '06

05 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Thunderbird 1.5.0.8 (Macintosh/20061025) Hi , As Quinn notes, nodes in /dev are a side-effect of having a driver instance. = 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.… sanjay yaragatti wrote: We have registered a serial port as character device.Can see the ports in /dev directory. But when I restart my system,the ports are lost.Is it the default behaviour? How can i make them persistent.I mean the ports should be available even after the m/c is restarted. Can anyone please tell me the way to do this? Load your device driver again, or install it in such a fashion that it is automatically loaded when your hardware (if any) is detected. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Ports lost after reboot..
by Quinn 05 Dec '06

05 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com 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 15:37 +0530 5/12/06, sanjay yaragatti wrote: We have registered a serial port as character device.Can see the ports in /dev directory. But when I restart my system,the ports are lost.Is it the default behaviour? Yes. On Mac OS X, /dev is managed by devfs, a completely synthetic file systems that's built at runtime, each time the system boots. In general, devices show up in /dev because I/O Kit has found them and created a driver. Eventually a "BSD client" matches on the device and it's this driver that creates the corresponding /dev entry. For serial devices, this "BSD client" is the IOSerialBSDClient object. This email sent to site_archiver(a)lists.apple.com

1 0

Ports lost after reboot..
by sanjay yaragatti 05 Dec '06

05 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=H0Z7rioG3LFSFUrTpEEV3NiQABooAMMh+o3izCISQoaqNXlIhyZUIZWeDw7i+sgCSigRXd37uwzZLAX2ArFFjXEeVwQtkmB8IfuHMNWJhu5zwYyQzPQMQ4QHDf+NB5j8mKzz06kPI16oBHPWcmhgRYFbl2kwBya0MSep15scbN4= ; Hi , We have registered a serial port as character device.Can see the ports in /dev directory. But when I restart my system,the ports are lost.Is it the default behaviour? How can i make them persistent.I mean the ports should be available even after the m/c is restarted. Can anyone please tell me the way to do this? Regards, Sanjay __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.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

Re: Booting a Mac from a remote image file.
by John Davidorff Pell 05 Dec '06

05 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:from:subject:date:to:x-mailer; b=OSFEDZgcX3+GCwCaMIxDDMAlPF7gOMipQt4TysctUOTfYqUQO4Z6gKFO4KsVJqmB4q7JwgAWrTJ+fzUtuO/45P/pAyptqR5ni35f7O3uCV83NK2hJDoMAxXruV+LQeE7L/Loq1IsMLLfXIrZISRpxhkSK+pP197REpPdokBKUTw= _______________________________________________ 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 smime.p7s

1 0