Red Hat Bugzilla – Bug 192082
System won't suspend with GFS2 file system mounted
Last modified: 2007-11-30 17:07:31 EST
Description of problem:
Machine won't suspend with GFS fs mounted
Version-Release number of selected component (if applicable):
RHEL 4 - U3, and FC5
Steps to Reproduce:
1. Mount a gfs fs
2. Try to suspend
3. Starts the process, but doesn't quite complete. Then wakes immediately back up
I am assuming this is a gfs2 problem.
Is this GFS2 or not? It says RHEL4 which makes me think not...
I can't see that its valid to suspend a node while its a member of a cluster, so
umount is the only option I think, since you must be a member of a cluster to
have GFS(2) mounted. If we were to suspend a node while it was a member of a
cluster its lack of response would presumably cause it to be fenced.
Using GFS(2) as a single node filesystem is a different matter. Can we confirm
that this is the case here? Some more details about the system would be useful
too if possible. I presume this was discovered on a laptop of some kind?
Yes, this is GFS2 in single node on a laptop. I'll reconfirm once I run on Beta 1.
Changing component to gfs2-kernel - lost track of this one since it was in the
kernel queue. Also, fixing summary.
Moving to 5.1
Abhi, please have a quick look at this one, with the emphasis on quick :-) If
this is something that can be solved relatively easily then please go ahead,
otherwise just document what you discover.
Do you have a suitable laptop on which to test this?
Marked NEEDINFO until we can get access to hardware that can reliably suspend.
Created attachment 157960 [details]
Fixes suspend to RAM/DISK issue w.r.t GFS2
Ok... I figured out the problem with the help of the laptop Rob sent me
(Thanks!). The kernel threads in gfs2, namely gfs2_scand, gfs2_logd,
gfs2_quotad, gfs2_glockd, gfs2_recoverd weren't doing anything when the suspend
mechanism was trying to freeze them.
And, from linux-2.6.22/Documentation/power/swsusp.txt:
"Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').
I found some kernel threads that don't do it, and they don't freeze
so the system can't sleep. Is this a known behavior?
A: All such kernel threads need to be fixed, one by one. Select the
place where the thread is safe to be frozen (no kernel semaphores
should be held at that point and it must be safe to sleep there), and
If the thread is needed for writing the image to storage, you should
instead set the PF_NOFREEZE process flag when creating the thread (and
be very careful)."
I put in calls to refrigerator() in the loops for all the daemons, however, I'm
not sure of the placement of these calls. I need some higher being
(swhiteho/dct-like) to bless this patch.
I tried this patch on the laptop and it works for me.
Also, this fixes only the gfs2 module. There're probably such kernel threads in
lock_dlm and dlm as well. Although, I suspect Rob isn't using dlm/lock_dlm on
his demo laptop and that fixing those isn't a priority.
Rob, it would be really nice if you could try this patch on your laptop and
tell me if it works for you.
Setting blocker flag to get patch into a 5.1 kernel build after it has been
reviewed, accepted upstream and submitted to rhkernel-list.
Abhi, add a macro to the top of daemon.c or a common gfs header (say gfs.h ?).
Otherwise, the patch looks good. Nice job !
The macro idea was NACKed. Sent original patch in comment #12 to cluster-devel.
Moving back to ASSIGNED. Accidentally moved to MODIFIED. Need to post patch to
rhkernel-list and mark POST.
Patch posted to rhkernel list
This patch in the "34" build is working for me. I have a GFS2 partition mounted
w/ and active build and, in initial test, it both suspends and resumes
successfully. Though, not the subject of this BZ, Hibernate (to disk) appears to
work. This is very light testing, but seems promising.
You can download this test kernel from http://people.redhat.com/dzickus/el5
Sucessfully tested using hibernate (my test system won't recover from a suspend
to ram for some reason) by copying a kernel source tree to a gfs volume, then
hibernating the system in the middle of the copy operation. The system recovered
and the copy continued. Once the copy finished, I diff'ed the two trees and they
are both the same.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.