From owner-freebsd-stable Thu Oct 12 9:59: 4 2000 Delivered-To: freebsd-stable@freebsd.org Received: from scully.zoominternet.net (scully.zoominternet.net [63.67.120.3]) by hub.freebsd.org (Postfix) with SMTP id 7C8BF37B66C for ; Thu, 12 Oct 2000 09:59:01 -0700 (PDT) Received: (qmail 26944 invoked from network); 12 Oct 2000 16:59:01 -0000 Received: from acs-24-154-28-99.zoominternet.net (HELO topperwein.dyndns.org) (24.154.28.99) by scully.zoominternet.net with SMTP; 12 Oct 2000 16:59:01 -0000 Received: from localhost (localhost [127.0.0.1]) by topperwein.dyndns.org (8.11.0/8.11.0) with ESMTP id e9CGxB801784 for ; Thu, 12 Oct 2000 12:59:11 -0400 (EDT) (envelope-from behanna@zbzoom.net) Date: Thu, 12 Oct 2000 12:59:11 -0400 (EDT) From: Chris BeHanna Reply-To: behanna@zbzoom.net To: FreeBSD-Stable Subject: Re: xl driver again? Re: mbuf leakage on 4.1.1-STABLE In-Reply-To: <20001012094914.F272@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 12 Oct 2000, Alfred Perlstein wrote: > [snip about possible mbuf leakage/starvation] > > Can we get a cocensus about which ethernet card is in use here? 3Com 3C905B (xl) in my case. > I've got several machines running fxp (intel etherexpress 100) > running under high loads without a single problem. I have a single > host with 'xl' that seems to be having the _exact_ same symptoms > as you guys are describing: > > Oct 9 15:24:38 xxx /kernel: xl0: no memory for rx list -- packet dropped! > Oct 9 15:25:10 xxx last message repeated 102 times > Oct 9 15:27:11 xxx last message repeated 473 times > Oct 9 15:30:08 xxx last message repeated 772 times Yes, this is exactly the problem I get. > ~ % netstat -m > 131/4864 mbufs in use: > 129 mbufs allocated to data > 2 mbufs allocated to packet headers > 128/4608/4608 mbuf clusters in use (current/peak/max) > 9824 Kbytes allocated to network (2% in use) > 1400 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines > > This leads me to believe that the driver is somehow tying down all > the mbufs for an extended period of time. If this problem still > hasn't been addressed in 4.1.1 it should be of concern as 'xl' is > supposed to be only second to 'fxp' in terms of quality and speed. > > The machine will recover after several minutes (without reboot), > but it's down long enough to trip our monitoring software that does > HTTP requests to the box. I haven't let mine sit to try to recover. I notice that I get no response at the console, and push the button. Next time, I'll let it sit awhile and see if it gets better. > I'll also note that the problem seems to be quite interesting as > I'm having nearly the exact same thing happen to me, basically the > card is fine for 2-3 days after reboot, then *BOOM* I run out of > mbufs, however mine does recover after a couple of minutes. Yup. > This problem has plagued the xl driver for nearly two years, If > there's anything I can do to help diagnose where the problem is > I'll be the first to try to provide any information requested. Ditto. I can report that I've seen this problem both with my custom kernel and with GENERIC (although I'll admit that I added IPFIREWALL to GENERIC for my particular test). > xl0: <3Com 3c905B-TX Fast Etherlink XL> rev 0x00 int a irq 12 on pci0.15.0 > xl0: Ethernet address: 00:10:4b:36:df:74 > xl0: autoneg complete, link status good (full-duplex, 100Mbps) Exact came card I have. > Thanks for any assistance, I sure need it. :( > > My solution so far has been to only get the fxp cards and replace > any xl's that I come across. I'm picking up a Netgear FA310TX (should be delivered any day now). At $20, it's cheap enough to see if it works any better for me. -- Chris BeHanna Software Engineer (at yourfit.com) behanna@zbzoom.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message