Support
All support resources for our products. Here you can find answers to frequently asked questions, discuss with other users, recover a lost license code or file a support request.
Forum closed
This forum was closed and turned into an archive effective April 21, 2018. It is no longer possible to create new topics or reply to existing topics.

Thanks everyone for all the great questions and contributions over the years.

Please use the Contact form to get in touch.

Remote Buddy Forum

Overview 

AuthorThread
User

05.01.2008 02:51:02
Re: Cannot unlock screen after waking MacBook when kernel extensions installed

This posting is older than 6 months and can contain outdated information.
I've been looking into the whole "keyboard and trackpad not available 
after waking from sleep" issue, digging deeply into the kernel 
sources, and here's what I've discovered:

1) after a (deep) sleep, the USB devices all have to be reenumerated, 
which means that IOKit will look for available drivers and user space 
apps that have registered for notifications (including Remote Buddy) 
will try to connect to the device through the respective 
IOUSB*UserClient.

2) Apple's HID drivers (IOUSBHIDDriver and subclasses) schedule an 
async read on all HID devices (including the IR Receiver, which, too, 
is just a HID device)

3) Right after, Remote Buddy receives notice from IOKit in userspace 
that a matching device (here: the built-in IR receiver) is available

4) To start from a clean basis, Remote Buddy's current release will 
make a ResetDevice() call via the user client for the respective 
IOUSBDevice.

5) In Kernel space, Apple's HID drivers still have their async reads 
scheduled. As the device is reset, they receive an error (errorcode 
kIOReturnUnderrun). Their standard reaction is to make a synchronous 
call to reset the interrupt pipe they are listening on.

6) The IOUSBController instance responsible for the device deadlocks.

Remote Buddy stack dump: 
[..] 
19 __ZN16IOUSBDeviceClass11ResetDeviceEv + 86 (in IOUSBLib) 
[0x1484d326] 
19 _IOConnectCallScalarMethod + 84 (in IOKit) [0x95e1b6a8] 
19 _IOConnectCallMethod + 300 (in IOKit) [0x95e1b3f6] 
19 _mach_msg_trap + 10 (in libSystem.B.dylib) [0x942fb8e6]

Remote Buddy - Kernel stack dump: 
19 _dtrace_get_cpu_int_stack_top + 543 [0x196afc] 
19 _mach_msg_overwrite_trap + 752 [0x126247] 
19 _ipc_kobject_server + 247 [0x12d165] 
19 _iokit_server_routine + 20111 [0x18d037] 
19 _is_io_connect_method + 468 [0x4379b0] 
19 
__ZN12IOUserClient14externalMethodEjP25IOExternalMethodArgumentsP24IOExternalMethodDispatchP8OSObjectPv 
+ 175 [0x439b71] 
19 com.apple.iokit.IOUSBFamily (3.0.3) + 117745 [0x698bf1] 
19 com.apple.iokit.IOUSBFamily (3.0.3) + 119708 [0x69939c] 
19 
__ZN13IOCommandGate9runActionEPFiP8OSObjectPvS2_S2_S2_ES2_S2_S2_S2_ + 
96 [0x41d9ce] 
19 com.apple.iokit.IOUSBFamily (3.0.3) + 70185 [0x68d229] 
19 _IORecursiveLockLock + 42 [0x401694] 
19 _lck_mtx_lock + 289 [0x19a781] 
19 _lck_mtx_lock_wait + 382 [0x13157e] 
19 _thread_block + 33 [0x1368fe] 
19 _thread_continue + 1181 [0x136691]

IOKit - Kernel thread 1 stack dump: 
19 __ZN10IOWorkLoop10threadMainEv + 24 [0x41bf88] 
19 __ZN10IOWorkLoop15runEventSourcesEv + 90 [0x41c2a6] 
19 __ZN22IOInterruptEventSource12checkForWorkEv + 183 [0x41d149] 
19 com.apple.driver.AppleUSBEHCI (3.0.3) + 14710 [0x88c976] 
[..] 
19 com.apple.iokit.IOUSBFamily (3.0.3) + 42613 [0x686675] 
19 __ZN9IOService14messageClientsEmPvj + 72 [0x409d40] 
19 __ZN9IOService17applyToInterestedEPK8OSSymbolPFvP8OSObjectPvES5_ 
+ 60 [0x409c9e] 
19 __ZN9IOService14applyToClientsEPFvPS_PvES1_ + 43 [0x409a21] 
19 
__ZNK15IORegistryEntry15applyToChildrenEPFvPS_PvES1_PK15IORegistryPlane 
+ 104 [0x406324] 
19 __ZN9IOService17applyToInterestedEPK8OSSymbolPFvP8OSObjectPvES5_ 
+ 137 [0x409ceb] 
19 __ZN9IOService13messageClientEmP8OSObjectPvj + 73 [0x409a6d] 
19 com.apple.driver.AppleUSBHub (3.0.3) + 19005 [0xbc4a3d] 
19 com.apple.driver.AppleUSBHub (3.0.3) + 16639 [0xbc40ff] 
19 _lck_mtx_lock + 289 [0x19a781] 
19 _lck_mtx_lock_wait + 382 [0x13157e] 
19 _thread_block + 33 [0x1368fe] 
19 _thread_continue + 1181 [0x136691]

IOKit - Kernel thread 2 stack dump: 
19 _thread_call_enter_delayed + 527 [0x13e987] 
19 com.apple.iokit.IOUSBFamily (3.0.3) + 66903 [0x68c557] 
19 com.apple.iokit.IOUSBFamily (3.0.3) + 66814 [0x68c4fe] 
19 __ZN9IOService14messageClientsEmPvj + 72 [0x409d40] 
19 __ZN9IOService17applyToInterestedEPK8OSSymbolPFvP8OSObjectPvES5_ 
+ 60 [0x409c9e] 
19 __ZN9IOService14applyToClientsEPFvPS_PvES1_ + 43 [0x409a21] 
19 
__ZNK15IORegistryEntry15applyToChildrenEPFvPS_PvES1_PK15IORegistryPlane 
+ 104 [0x406324] 
19 __ZN9IOService17applyToInterestedEPK8OSSymbolPFvP8OSObjectPvES5_ 
+ 137 [0x409ceb] 
19 __ZN9IOService13messageClientEmP8OSObjectPvj + 73 [0x409a6d] 
19 com.apple.driver.AppleUSBHub (3.0.3) + 19005 [0xbc4a3d] 
19 com.apple.driver.AppleUSBHub (3.0.3) + 17104 [0xbc42d0] 
19 com.apple.driver.AppleUSBHub (3.0.3) + 31581 [0xbc7b5d] 
19 com.apple.iokit.IOUSBFamily (3.0.3) + 12080 [0x67ef30] 
19 
__ZN13IOCommandGate9runActionEPFiP8OSObjectPvS2_S2_S2_ES2_S2_S2_S2_ + 
261 [0x41da73] 
19 com.apple.iokit.IOUSBFamily (3.0.3) + 11763 [0x67edf3] 
19 _IORecursiveLockSleep + 67 [0x401783] 
19 _lck_mtx_sleep + 87 [0x130a08] 
19 _thread_block + 33 [0x1368fe] 
19 _thread_continue + 1181 [0x136691]

IOKit - Other kernel thread stack dumps: 
19 _thread_call_enter_delayed + 527 [0x13e987] 
19 __ZN18IOTimerEventSource17timeoutAndReleaseEPvS0_ + 58 [0x41f8ac] 
19 com.apple.iokit.IOUSBFamily (3.0.3) + 70185 [0x68d229] 
19 _IORecursiveLockLock + 42 [0x401694] 
19 _lck_mtx_lock + 289 [0x19a781] 
19 _lck_mtx_lock_wait + 382 [0x13157e] 
19 _thread_block + 33 [0x1368fe] 
19 _thread_continue + 1181 [0x136691]

7) As the IOUSBController instance has deadlocked, but is responsible 
for handling the communication for all other devices connected to the 
same port, all other devices connected to the same port will no longer 
appear to work, as data is neither handed to them nor polled from them.

8) As Santa Rosa MacBook Pros internally connect keyboard, trackpad 
and built-in IR receiver to the same USB port, unfortunate timing can 
lead to the ResetDevice() (in user space) and ClearStall() (on 
IOUSBPipe, in kernel space) calls to deadlock the IOUSBController 
instance handling all three devices. That's also, why all other USB 
ports will continue to work.

Said simply, any application that uses the quite common and widely 
used approach of accessing a USB device from user space and that makes 
a call to ResetDevice() on the IOUSBDevice can potentially deadlock 
the IOUSBController handling the port of the USB device - consequently 
disabling all I/O handling for all other devices connected to the same 
USB port.

So, if you are using Remote Buddy on a Santa Rosa MacBook Pro under 
Leopard, your keyboard and trackpad may loose connection after a 
(deep) sleep. I would like to underline, though, that the bug leading 
to this actually sits in Apple's IOUSBFamily.kext and not Remote Buddy 
or its kernel extension. That you see that problem only after 
installing Remote Buddy's kernel extension is explained easily: 
without it installed, Remote Buddy's own IR Receiver USB driver - 
which currently resides entirely in userspace - is not registering for 
notifications for the device and thus will also not try to initialize 
it using ResetDevice().

That said, Apple has done a lot of (otherwise excellent) work on the 
IOUSBFamily in Leopard, so it's not surprising that there are still 
bugs left. I'm confident that Apple will fix it with one of the next 
OS 10.5.x updates.

While the usage of any other apps that access USB devices from 
userspace might still give you problems until Apple fixes the bug, 
Remote Buddy's next version will feature a completely new set of 
drivers that - among other things - also elegantly works around the bug.

As a temporary fix until the release of the next Remote Buddy update 
(and updates to any other apps accessing USB HID devices), you may 
want to disable safe sleep.

Best regards, 
Felix 

Thread-display::