Bug 2935 - CIFS prevent to enter ACPI S3 state
Summary: CIFS prevent to enter ACPI S3 state
Status: RESOLVED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 2.6
Hardware: All Linux
: P3 critical
Target Milestone: ---
Assignee: Steve French
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-01 05:40 UTC by Eric Valette
Modified: 2005-08-31 09:19 UTC (History)
1 user (show)

See Also:


Attachments
As requested the debugData file (1.18 KB, text/plain)
2005-08-04 00:23 UTC, Eric Valette
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Valette 2005-08-01 05:40:53 UTC
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.
Comment 1 Steve French 2005-08-03 22:31:35 UTC
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).
Comment 2 Eric Valette 2005-08-04 00:23:19 UTC
Created attachment 1355 [details]
As requested the debugData file
Comment 3 Eric Valette 2005-08-04 00:34:05 UTC
You are right : the message says "cifsd" not "cifsoplockd".
Comment 4 Steve French 2005-08-04 01:23:47 UTC
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.
Comment 5 Eric Valette 2005-08-04 02:23:26 UTC
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?
Comment 6 Steve French 2005-08-31 09:19:42 UTC
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