> I'm fairly baffled. I tried for many hours to reproduce the problem in
two seperate sets of systems here, and completely failed. I left
buildworlds, cvs updates, blah blah blah, running for 96 hours across
pools of clients and servers and no hint of the problem. I also use NFS
daily on my primary workstation at work, as well as in my normal
development setup with diskless crashboxes. So indeed, there must be some
very specific piece of the picture that I'm not reproducing, such as a
specific network card, or there's a race condition that requires very
specific timing, etc.
How fast are your systems, speaking of which? I live in the world of 300-500 mhz machines at work, and 300-800 mhz boxes at home. If you're using multi-ghz boxes, that could well be the distinguishing factor between our configurations...
<snip>
client is an intel pentium II 300mhz with 256meg ram and 1gig of swap. server is an athlon XP 2200 with 512meg ram and 1gig of swap.
I can certainly spend some time trying to get some proper debug based on what you have said in your email. I shall look into setting up a serial console etc.
In the meantime another piece of information which might be helpful is this. Looking at the wtmp to see when I rebuilt my world/kernel I can see this:
reboot ~ Tue Oct 21 20:44 reboot ~ Wed Oct 15 19:36
(These times are in BST which is +5 hours from east coast US).
On the Oct 15th kernel NFS was working perfectly (and before that). From the Oct 21st kernel it has always locked up in this way. So something between those two dates was commited which broke this for us. Another way of me debugging this I guess is to backtrack my world to each date in between systematically and find the exact date it breaks and look at the commits.
Matt.
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
