> Thanks for the response. > Are you saying that instead of using the default thread (events/0) for scheduling the work, I should be using the dedicated thread for scheduling the work? Yes that's what i meant. >We did this experiment and it worked fine. However, I want to get to the root cause and that would require some utility to display (or examine) >the status of the work present on the queue. What happens when you use the default thread for scheduling the work? Does the system freeze when the issue occurs? You need to look at the various tasks / threads running on the system and what is their status when the issue occurs. You can use SYSREQ Magic key to see what tasks are running. Also enable some of the debugging features under Kernel hacking like lock debugging etc. This will give some more pointers. > > Do you have any suggestion on that? > How about changing the work queue to a Kernel Thread. Are there any potential issues with this? We did this - changed the work queue to >Kernel Thread the system is behaving as expected how. However, I am not sure if having too many threads is a good idea in the system and >hence contemplating the idea. How many new threads are you creating? If its only one I dont see a problem. But if the root cause is known a most appropriate solution can be thought. Thanks, Maulik -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
