Re: NFS trouble

Ugh. While writing this mail I've noticed Sean McNeils mail. I suppose 
thats the answer right there. Damn, I even read about the problem several 
times right here on this mailing list, it just didn't occur to me that it 
could be the NIC...

Well. For completeness' sake I'll still include the response to rwatson_at_ 
below. There's some hardware info included as well.

Thanks a lot for answering, all of you.

Benjamin



> When you're experiencing this problem, can the NFS client ping the NFS
> server?

Yes.

> Are other NFS clients able to continue to access the NFS 
> server without problems?

Partially. Other clients can access parts of the exported share. It 
appears that as soon as they access the directory in which the first 
program froze, they freeze as well.

> It might be interesting to use tcpdump to see if the client stops
> sending RPCs or not, and if not, whether the server responds to them.  

I'll try the next time I see the problem. It's not easily reproducable, 
sometimes it freezes when I try to store a 2KB text file, sometimes after 
being able to copy a few hundred MB. I tried to reproduce it just now by 
copying random stuff around, of course that didn't work. Seems the 
problem only appears when I'm using valuable files... *sigh*.

> If you set debug.mpsafenet=0 in loader.conf, does the problem go away? 

I'll try it and report.

> Also, finally, what ethernet device(s) are you using, and are there any
> notes about those devices in the dmesg output? 

I'm using the Realtek onboard Gigabit NIC on my MSI K8N Neo2 Platinum 
mainboard. Ooooh... wait... could it be that Realtek once again manages 
to fuck a machine of mine up in a weird way? Either way, the adapter is 
described in the manual as Realtek 8110S chip. FreeBSD reports it as:

re0: <RealTek 8169S Single-chip Gigabit Ethernet> port 0xac00-0xacff mem
     0xf3000000-0xf30000ff irq 16 at device 13.0 on pci2
miibus0: <MII bus> on re0
rgephy0: <RTL8169S/8110S media interface> on miibus0
rgephy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 
         1000baseTX-FDX, auto
re0: Ethernet address: 00:11:09:65:fc:0e


Another bit of information: Last time this happened, the freeze was 
reproducable. I did the following:
- Try to save a text file in kate to the NFS share, notice that kate was 
  frozen in nfsfsync state. 
- umount -f the share
- See that kate is unfrozen, and that it displays an error message about
  not being able to write the file.
- remount it
- Try to save the still open file again, notice that kate freezes again.
- After changing the text file, saving worked.

So I think this is triggered by a certain bytestream, it appears to not be 
totally random.