Deadlock during Resume with OCHD

[Stefano Voulaz]

Hello gurus,
I'm facing a nasty deadlock issue while resuming a CE 6.0 R3 device after suspend. The problem occurs only if OHCD driver is included in the image and when the system is suspended while an application is running from a storage device (i.e., NAND or SD) and accessing data on it.

Since the USB host controller does not support HCD_SUSPEND_RESUME (but only HCD_SUSPEND_ON_REQUEST), OHCD resume code - located in public\common\oak\drivers\usb\hcd\ohcd2\chw.cpp, function CHW::CeResumeThread() - simply reinitializes the controller.

During this process, the registry key [HKLM\ShimEngine] is accessed (unloading the library) while the file system is [possibly] locked on an acces performed by the application running from the storage device - whose volume has not been remounted yet. So the deadlock.

The same problem does not happen if the application relies only on RAM file system.

Any suggestion on where to go from here?
Thank you in advance - Stefano

[Stefano Voulaz]

After some more investigation, it *seems* that the problem depends on the boot registry being paged out.
At resume, the USB driver is unloaded (thus accessing the registry) while the volumes are not yet mounted (the volume notifications have not been broadcast).
I expected the registry access to be suspended somehow while waiting for the volumes, but instead the system hangs in ReadFileWithSeek after the page fault.
Any suggestions?
Bye
Stefano

Post by Stefano Voulaz
Hello gurus,
I'm facing a nasty deadlock issue while resuming a CE 6.0 R3 device after suspend. The problem occurs only if OHCD driver is included in the image and when the system is suspended while an application is running from a storage device (i.e., NAND or SD) and accessing data on it.
Since the USB host controller does not support HCD_SUSPEND_RESUME (but only HCD_SUSPEND_ON_REQUEST), OHCD resume code - located in public\common\oak\drivers\usb\hcd\ohcd2\chw.cpp, function CHW::CeResumeThread() - simply reinitializes the controller.
During this process, the registry key [HKLM\ShimEngine] is accessed (unloading the library) while the file system is [possibly] locked on an acces performed by the application running from the storage device - whose volume has not been remounted yet. So the deadlock.
The same problem does not happen if the application relies only on RAM file system.
Any suggestion on where to go from here?
Thank you in advance - Stefano