Messages in this thread |  | | | Date | Thu, 28 May 2009 13:45:27 +0200 | | From | Pavel Machek <> | | Subject | Re: 2.6.29.4: hibernation fails with large kernel trace |
| |
Hi!
> > The process "fuser" is stuck down in the fuse code awaiting a response > > or something. I'd suspect that this is the cause of the freezing > > failure: > > Yup, the 'gvfs-fuse-daemon' process is already in the refrigerator, so > it cannot complete the request from the 'fuser' process. > > The solution is simple, really: just allow the 'fuser' task to freeze > despite the fact that it's inside a syscall. There's the small detail > of actually implementing this, without breaking everything else... > > What complicates the above is that we need to enable freezing not just > inside fuse callbacks, but in the VFS as well. E.g. sys_rename() > sleeping on i_mutex needs to be freezable as well, otherwise another > thread that is already frozen and holding that i_mutex will block that > rename. > > So, > > a) we need some sort of mechanism to selectively disable freezing only > for those syscalls which might (directly) touch hardware state. It > _hopefully_ should be enough to do so with read, write and ioctl, > > b) we need to re-enable freezing for these in fuse. > > That's the theory. I promised a prototype some time ago but haven't > yet got around to doing it.
In the meantime, people should stop/restart fuse around suspend/hibernation, I guess... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
|  |