On Tue, 3 Feb 2009, Alan Stern wrote:
On Tue, 3 Feb 2009 kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote:On Tue, 3 Feb 2009, Jean-Francois Moine wrote:On Tue, 3 Feb 2009 13:15:58 -0600 (CST) kilgota@xxxxxxxxxxxxxxxxxxxxxx wrote:Why is there 2 sq905 processes?I of course do not fully understand why there are two such processes. However, I would suspect that [sq905/0] is running on processor 0 and [sq905/1] is running on processor 1. As I remember, there is only one [sq905] process which runs on a single-core machine.Indeed, the problem is there! You must have only one process reading the webcam! I do not see how this can work with these 2 processes...The problem, then, would seem to me to boil down to the question of whether that is up to us. Apparently, a decision like that is not up to us, but rather it is up to the compiler and to the rest of the kernel to decide.Nonsense. It's simply a matter of how you create your workqueue. In the code you sent me, you call create_workqueue(). Instead, just call create_singlethread_workqueue(). Or maybe even create_freezeable_workqueue(). Alan Stern
OK, seems one way out, might even work. I will definitely try that. Update. I did try it. No it does not work, sorry. :/ I changed the line dev->work_thread = create_workqueue(MODULE_NAME); to read dev->work_thread = create_singlethread_workqueue(MODULE_NAME);As a result, I can definitely report that only _two_ processes were frozen when the cord was pulled, named [svv] and [sq905].
I am sure that the attached log file of the oops looks a little bit different from the previous ones. It must, after all.
While you have this matter on your mind, I am curious about the following:As the code for the sq905 module evolved through various stages, the only occasion on which any real trouble arose was at the end, when we put in the mutex locks which you can see in the code now. Before they were put in, these problems which we are discussing now did not occur. Specifically, there was not any such problem about an oops caused by camera removal until the mutex locks were put in the code. And I strongly suspect -- nay, I am almost certain -- that with that the same code you are looking at now, the oops would go away if all those mutex locks were simply commented out and the code re-compiled and reinstalled. Can you explain this? I am just curious about why.
Attachment:
singlethread.txt.bz2
Description: Binary data
