Distribution: debian testing Hardware Environment: dell inspiron 8600, gf5200 Software Environment: self compiled kernel 2.6.9 with S3_late_bios patch from http://www.loria.fr/~thome/d600/ binary nvidia driver 66.29 KDE 3.3.1 Problem Description: With the patch from http://www.loria.fr/~thome/d600/ and temporarily stopping several services and modules, my laptop suspends to the S3 state without any problems. After resuming, everything works fine except the open smb connections. Accessing to a samba resource (smbd 3.0.8) results in a smb_add_request timed out error (see dmesg). Doing an ls in a mounted directory returns a Input/output error. Workaround: kill all applications accessing the samba resource and rmmod smbfs before suspending the system. Without unloading the smbfs module BEFORE suspending to RAM, a reboot is necessary to access to the smb resource again. please make the smbfs module suspend-to-RAM safe. Steps to reproduce: - edit a document located on a mounted samba share - suspend the system to the S3 state - resume - try to access the document, application will hang
Created attachment 4180 [details] dmesg
This bug is still present in 2.6.11 using Gentoo. This bug is basically a showstopper for using a laptop (->suspend) in a local network (->samba). Is this the wrong place to report this bug, does this belong to samba.org?
I'm not sure but I don't think any network filesystem can survive from a suspend/resume cycle (suspend will break network connection). To me, a user script should unmount all network filesystems before suspend and remount it after resume.
I am not sure about that, I think Windows for example survives a suspend/resume cycle. But what is definatively a bug is the fact that if you do not umount a samba share, you'll enter a error state upon resume which is not repairable. You neither can umouunt nor mount, (even with --force), reload modules, etc... It's not just loosing the connection but the necessity to reboot what I'm talking about here. But I think I found an acceptable workaround: It seems to be sufficient to lazy unmount (umount -l /sambashare/) before resume and remount the share after resume. The application does not crash and is fully functional after resuming. In my opinion, the lazy unmount should be integrated in the suspend hook of smbfs (if there is any). Still better than reboot...
this problem is still present with 2.6.15-rc2-git2 and associated grekh-all. in contrast, nfs survives suspend/resume very nicely. actually, if i copy some large file and suspend during the processs, copying is finished after resuming. smbfs mounts are completely unaccessible and produces similar timeouts for me.
SMBFS is being deprecated, you should be using CIFS instead (see http://lwn.net/Articles/183693/) IMO this bug should be closed - please try CIFS instead, and if you find some problem with cifs please report it
Please close this bug if the problem doesn't appear in recent kernels (2.6.18 and later).