I tried to use suspend to RAM on my laptop. It starts suspending but then iussue a message saying that one CIFS kernel thread is not suspended and immediately resume. I guess it is the "cifsoplockd" kernel thread.
I have not seen this behavior before - but will try to attempt it - could you do a quick experiment and see if 1) it is reproducible 2) if so, does "kill -9" of the oplockd thread, prior to the suspend allow you to suspend successfully (that would verify your theory that the oplockd thread is the one) Note that fixes were made (roughly cifs version 1.34) to allow the cifs code to more gracefully handle the cifsoplock (and cifsd threads) to be killed (without oopsing) - not something we want to recommend - but for the purposes of this test it may be helpful to isolate which thread won't stop. Also note, before you try suspending, the contents of /proc/fs/cifs/DebugData, which allows me to tell whether there were any pending requests on the network from cifs, when the suspend was attempted. My intuition is that the problem thread is more likely to be cifsd (the demultiplex thread) if any (not the cifsoplockd thread).
Created attachment 1355 [details] As requested the debugData file
You are right : the message says "cifsd" not "cifsoplockd".
Now I wonder which one of the three cifsds it is (should be one cifsd per socket to a distinct server). Do you know how to "echo t > /proc/sysrq-trigger" or equivalent to dump a stacktrace of threads in the kernel (it dumps to the dmesg log)? Are you comfortable with that - if symbols are built in your kernel it might show us if one of the three cifsds is blocked in an unexpected location.
In theory, I have no problem to do that as I have been developping OS for the last 15 years... But it is my professionnal laptop and I have little time so if you are able to reproduce this, it would be the fastest path. Besides, when I manage to suspend the PC does not come up, I have to remove the battery so anyway, it would no solve my suspend to RAM problem. Additionnal question : when do you want to have the echo t > /proc/sysrq-trigger trace?
I believe that this is now fixed in the current cifs-2.6.git tree on kernel.org and will be in cifs 1.36.tar.gz Patch is http://kernel.org/git/?p=linux/kernel/git/sfrench/cifs- 2.6.git;a=commitdiff;h=16abbecdad3367c76c12537450eba0d86943fe2c