On Thu, Apr 19, 2012 at 6:39 PM, Frédéric L. W. <fredlwm@xxxxxxxxxxx> wrote: > On Thu, Apr 19, 2012 at 03:19:13PM -0500, Steve French wrote: >> On Thu, Apr 19, 2012 at 2:43 PM, Frédéric L. W. wrote: >> > >> > I captured a log with 'tcpdump', but I don't think it's of any use. It >> > stopped logging at 16:01 but the hang happened after that. It didn't log >> > anything from the problematic 'ls', 'kill -9' and 'umount /mnt/ntfs2'. >> >> Maybe capture a log (with netmon on wireshark) on the windows side >> to see what the trace shows. >> >> Presumably some odd networking issue with virtual box, but >> may be useful to see which command fails/timesout by >> looking at dmesg output on the client (running the >> test after enabling /proc/fs/cifs/cifsFYI setting it >> to 7 e.g.). >> >> At least with the server returning maxmpx of 50, it is less >> likely to be the bug with too many outstanding requests. > > I noticed that if I change the connection in VirtualBox from NAT to > Bridged Adapter, the hangs don't occur (at least after about 2h). > > Are you still interested in a log from Windows in NAT mode, where the > hangs happen, or this is definitely an issue / "feature" in VirtualBox ? > > What I don't know is if CIFS could do anything to exit gracefully > instead of deadlocking the application trying to access the share. I would love to investigate in more detail (obviously if easy cifs changes can lessen or resolve strange networking problems, we are all for it) but I have other problems with virtualbox setup at the moment that make it hard for me to see whether I run into the same issue. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
