Description of problem: Machine won't suspend with GFS fs mounted Version-Release number of selected component (if applicable): RHEL 4 - U3, and FC5 How reproducible: 100% 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 Actual results: Won't suspend Expected results: Should suspend Additional info:
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. See linux-2.6.22/Documentation/power/kernel_threads.txt. 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 add: try_to_freeze(); 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 http://post-office.corp.redhat.com/archives/rhkernel-list/2007-June/msg02346.html
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.
in 2.6.18-34.el5 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. http://rhn.redhat.com/errata/RHBA-2007-0959.html