benlutz at datacomm.ch
Mon Oct 11 15:11:43 PDT 2004
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@
below. There's some hardware info included as well.
Thanks a lot for answering, all of you.
> When you're experiencing this problem, can the NFS client ping the NFS
> 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,
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20041012/7dd9857a/attachment.bin
More information about the freebsd-current