Date: Thu, 04 Apr 2002 21:04:09 -0800 From: "Bruce A. Mah" <bmah@FreeBSD.ORG> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: Will Froning <wfroning@angui.sh>, hackers@FreeBSD.ORG Subject: Re: Fatal trap 12: page fault while in kernel mode Message-ID: <200204050504.g355493C001200@intruder.bmah.org> In-Reply-To: <15532.29114.310072.957330@grasshopper.cs.duke.edu> References: <20020403181854.I42720-100000@angui.sh> <15532.29114.310072.957330@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
If memory serves me right, Andrew Gallatin wrote: > > Will Froning writes: > > I have a 4.5-RELEASE-p2 box that is my Firewall/NAT/NFS server. As a > > NFS client I have a RH7.2 linux box. When I do massive NFS writes to > > my FBSD (from RH7.2 box), I get a panic. I've attached the info I got > > from my debug kernel. > > > > While the fix being discussed by Peter & others will prevent panics, > the linux box will still run your server out of mbufs clusters. This > is happening because the linux box is using a 16K write size over UDP > by default. This is a stupid default. If there is any lossage > between the hosts (eg, any packets get dropped), more and more packets > will end up on the reassembly queues. Eventually, all your cluster > mbufs will be there. I was discussing this with some of my cow-orkers, as we've had a similar situation (cluster mbufs getting temporarily depleted on a 4.5-RELEASE-p2 NFS server with Linux and FreeBSD clients, but no kernel panics). Shouldn't the net.inet.ip.maxfragpackets sysctl variable (introduced in 4.4-RELEASE) limit the number of fragments on the reassembly queue(s)? This value looks to be about 1/4 the number of cluster mbufs, by default. Bruce. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204050504.g355493C001200>