Problems with workqueue
Hi All,
I am facing a problem with Work Queues and need some help debugging. We are using 2.6.22 Kernel. I know that it is old kernel version, but this kernel version was chosen for the product almost a year back and we are not in a position to change the kernel version due to time constraints.
Problem description
We use work queues for the second half of the ISR with a touch screen driver. Most of the times, everything works fine. However, occasionally, the work does not seem to get a chance to execute.
Questions:
a) What is the best way to monitor the work execution on the work queues?
b) Is it possible that the Kernel flushes the work from the work queue sometimes and makes the work unavailable?
c) How to make sure that the work is available on the work queue and how to check this?
Any suggestions on this will be really helpful.
with regards,
NS.
Quoted 11 lines · NS
Hi All,
I am facing a problem with Work Queues and need some help debugging. We are using 2.6.22 Kernel. I know that it is old kernel version, but this kernel version was chosen for the product almost a year back and we are not in a position to change the kernel version due to time constraints.
Problem description
We use work queues for the second half of the ISR with a touch screen driver. Most of the times, everything works fine. However, occasionally, the work does not seem to get a chance to execute.
Are you using the default work queue or a dedeicated work queue for your touch screen driver?
If you are using the default work queue you can try using a dedicated work queue in your touch screen driver and see if this resolves the issue.
Then debug further to find a root cause.
Regards,
Maulik
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 3 lines
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