...and I'd like to point out that I've done a ton of NFS (v3 only, since I'm talking to hosts running Hoary---yes, really) with the Intel NIC and had no problems whatsoever. To everyone who is blaming NFS here, TRY NETCAT. And DO NOT try scp or ssh because they're doing crypto which will slow down your transfer rates significantly---for every 2x slowdown, it might cause the bug to take 2^x longer to manifest (did for me, anyway). Instead, try just shoving data as fast as you can via nc ---I was using tar on both ends of the pipeline because I was trying to actually get data moved, but if you're just debugging this, shove /dev/zero through nc at one end and dump it to /dev/null at the other. And then let it sit there for your typical time-to-failure (times as- much-patience-as-you-have). If that doesn't work, try disk activity as well---maybe you have my bug, where things only went south when there was lots of heavy activity on the PCI bus (see my previous comment on this thread) but it was perfectly fine if it was just an nc pipeline that wrote to non-PCI disks or to nowhere. [I haven't rigorously read the entire thread in this bug report here, but it sounds more and more like the problem isn't NFS, but your NIC, and that you're not seeing it in non-NFS applications either because you're using things that don't hit the net as hard, or because you are, but you're not also doing file I/O.]
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/661294 Title: System lock-up when receiving large files (big data amount) from NFS server -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
