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
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