From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Description of problem: Moderate load from a Samba client to a Samba server results in a wedged smbfs driver. Samba server is an SMB export of a 120GB SATA RAID-1 mirror. (FC2) Samba client is an FC3 system (but also occurred with FC2.) Client has experienced the error with all kernels since FC2. Problem appears to be caused when either a large amount of data is transferred in a short amount of time, or due to special characters in filenames. As both client and server in this case are Linux, Samba Unix Extensions are in use, which may be relevant. Samba server reports NO ERRORS. Rebooting the client (or if you get lucky waiting long enough for a timeout or reset) will restore connectivity. Also, Mac OS X has no issues with the same export. i.e. truly appears to be an smbfs bug. Issue has apparently been mentioned on lkml, but no takers so far, as near as Google can tell me. Some other bugs (e.g. 122283) might or might not be duplicates. Dmesg says: smb_add_request: request [08dc9dc0, mid=339] timed out! smb_add_request: request [08dc9ee0, mid=340] timed out! smb_add_request: request [08dc9ca0, mid=341] timed out! smb_add_request: request [08dc9b80, mid=342] timed out! smb_add_request: request [08dc9dc0, mid=344] timed out! smb_add_request: request [08dc9b80, mid=345] timed out! smb_add_request: request [08dc9040, mid=362] timed out! smb_add_request: request [08dc9b80, mid=363] timed out! smb_add_request: request [08dc9dc0, mid=364] timed out! smb_add_request: request [08dc9b80, mid=365] timed out! smb_add_request: request [08dc9dc0, mid=366] timed out! smb_add_request: request [08dc9ee0, mid=367] timed out! smb_add_request: request [08dc9dc0, mid=368] timed out! smb_add_request: request [08dc9ee0, mid=369] timed out! smb_add_request: request [08dc9dc0, mid=370] timed out! smb_add_request: request [08dc9b80, mid=371] timed out! smb_add_request: request [08dc9dc0, mid=372] timed out! smb_add_request: request [08dc9b80, mid=373] timed out! smb_add_request: request [08dc9dc0, mid=374] timed out! smb_add_request: request [08dc9ee0, mid=375] timed out! smbiod_handle_request: smbiod got a request ... and we don't implement oplocks! smb_add_request: request [08dc9dc0, mid=376] timed out! smb_add_request: request [08dc9ee0, mid=377] timed out! smb_add_request: request [08dc9dc0, mid=378] timed out! smb_receive_header: short packet: 0 smb_add_request: request [08dc9b80, mid=379] timed out! smb_add_request: request [08dc9dc0, mid=380] timed out! smb_add_request: request [08dc9ee0, mid=381] timed out! Version-Release number of selected component (if applicable): kernel-2.6.9-1.667 custom build How reproducible: Always Steps to Reproduce: 1. Export an SMB share using Samba on a server. 2. Connect using smbfs 3. Mess around with it for a while, esp. in a GUI file browser Additional info:
I enabled all debug levels in the Makefile for smbfs and rebuilt it. I then directed syslog to log all kernel messages to a file, which I have attached. (SMB_DEBUG, SMB_DEBUG_VERBOSE, SMB_MALLOC, SMB_TIMESTAMP) Some pretty impressive spam, but what you are looking at is a bunch of successful SMB reads (ls, stat, and so on) from the command line followed by an attempt to read the same directory from within Konqueror, resulting in a hang. The relevant log messages are toward the bottom of the file.
Created attachment 106551 [details] Log of kernel debug output from smbfs.
Created attachment 106552 [details] Log of kernel debug output from smbfs.
Sorry about the attachment spam, Bugzilla choked on the 800K uncompressed attachment. Reattached as a .gz.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
This bug has been automatically closed as part of a mass update. It had been in NEEDINFO state since July 2005. If this bug still exists in current errata kernels, please reopen this bug. There are a large number of inactive bugs in the database, and this is the only way to purge them. Thank you.