Bug 656992 - cannot suspend: "Freezing of tasks failed after 20.00 seconds (1 tasks refusing to freeze)"
Summary: cannot suspend: "Freezing of tasks failed after 20.00 seconds (1 tasks refusi...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Matthew Garrett
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 656991 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-24 16:32 UTC by Ben Liblit
Modified: 2013-10-08 17:50 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-10-08 17:50:01 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
example dmesg output from suspend failure (1.92 KB, text/plain)
2010-11-24 16:32 UTC, Ben Liblit
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Launchpad 763986 0 None None None Never

Description Ben Liblit 2010-11-24 16:32:01 UTC
Created attachment 462687 [details]
example dmesg output from suspend failure

When trying to suspend my ThinkPad X61 laptop (via keypress, lid closure, panel menu, etc.), about two tries in three fail.  Diagnostic information in dmesg and /var/log/messages refers to "Freezing of tasks failed after 20.00 seconds (1 tasks refusing to freeze)".  The specific task is usually (but not always) gnome-do.  The call trace varies a bit, but *always* mentions fuse_request_send called by autoremove_wake_function at or near the top of the trace.

Comment 1 Ben Liblit 2010-11-24 16:32:44 UTC
I neglected to mention the kernel version.  I am using kernel-2.6.35.6-48.fc14.i686.

Comment 2 Ben Liblit 2010-12-08 17:40:50 UTC
*** Bug 656991 has been marked as a duplicate of this bug. ***

Comment 3 Matthew Garrett 2010-12-09 17:01:35 UTC
Are you using any fuse filesystems?

Comment 4 Ben Liblit 2010-12-09 20:22:29 UTC
I have up to three fuse-related file systems in use:

(1) This machine dual-boots Fedora and Windows 7.  At all times when the machine is up and running Fedora, the main Windows 7 NTFS partition is also mounted.  It is listed in /etc/fstab as having file system type "ntfs", but running "mount" shows that this is actually mounted using file system type "fuseblk".

(2) Whenever I am logged in with my standard GNOME desktop, "gvfs-fuse-daemon" is mounted on $HOME/.gvfs with file system type type "fuse.gvfs-fuse-daemon".  This lasts for my entire login session.

(3) Occasionally during a login session, I may mount a remote file system via fuse's sshfs.  This comes and goes; it might be mounted during some suspend attempts but unmounted during others.

Comment 5 Matthew Garrett 2010-12-09 20:31:47 UTC
Ok. Are you able to test whether the failure occurs without the ntfs and sshfs filesystems being mounted?

Comment 6 Ben Liblit 2010-12-12 03:49:16 UTC
The failure does *not* occur with the ntfs and sshfs filesystems unmounted.

Since the problem is nondeterministic, I experimented for a few days with the ntfs filesystem mounted or unmounted.  (The sshfs filesystem was never mounted.)  With ntfs mounted, I had 11 successful suspends and 4 failures.  With ntfs unmounted, I had 8 successful suspends and 0 failures.

Comment 7 Ben Liblit 2012-01-23 15:40:52 UTC
Problem still appears as originally described under Fedora 16, with:

    fuse-sshfs-2.3-1.fc16.i686
    gnome-do-0.8.5-7.fc16.i686
    kernel-3.1.9-1.fc16.i686
    ntfs-3g-2011.4.12-5.fc16.i686

Comment 8 Josh Boyer 2012-02-28 18:44:54 UTC
There are some known issues in regards to fuse and suspend/resume.  Essentially, a task stuck in the fuse layer can cause the freezer to give up and suspend will abort.

http://lists.debian.org/debian-kernel/2011/10/msg00412.html

There is work ongoing upstream for this but nothing explicit that I see in the tree yet.  I'm going to move this bug to rawhide for now.  In the meantime, unmount the fuse filesystems before suspending.

Comment 9 Fedora End Of Life 2013-04-03 20:10:15 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Comment 10 Josh Boyer 2013-09-18 20:22:54 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.

Comment 11 Josh Boyer 2013-10-08 17:50:01 UTC
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.


Note You need to log in before you can comment on or make changes to this bug.