From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 12:39:16 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05562106564A for ; Wed, 27 Apr 2011 12:39:16 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id D6C478FC15 for ; Wed, 27 Apr 2011 12:39:15 +0000 (UTC) Received: by pvg11 with SMTP id 11so1524253pvg.13 for ; Wed, 27 Apr 2011 05:39:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.30.39 with SMTP id p7mr2189944pbh.34.1303907955284; Wed, 27 Apr 2011 05:39:15 -0700 (PDT) Received: by 10.68.60.161 with HTTP; Wed, 27 Apr 2011 05:39:15 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> Date: Wed, 27 Apr 2011 14:39:15 +0200 Message-ID: From: Olivier Smedts To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD current mailing list , Mike Tancsa Subject: Re: problems with em(4) since update to driver 7.2.2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 12:39:16 -0000 2011/3/31 Jack Vogel : > This problem happens for only one reason, you have insufficient mbufs to > fill your rx ring. Its odd that it would differ when its static versus a > loadable > module though! > > With the 7.2.2 driver you also will use different mbuf pools depending on > the MTU you are using. If you use jumbo frames it will use 4K clusters, > if you go to 9K jumbos it will use 9K mbuf clusters. The number of these > allocated by default is small (like 6400 small :). > > I would use 'netstat -m' to see what the pools look like. Now that I thin= k > about it, the reason it might fail as loaded while not as built in is you > get > allocation of the mbufs first when static, and something else is taking t= hem > before you can load when loadable?? Sorry to be quite late on this, Here is what gives me netstat -m with my new 9-CURRENT kernel but with old (working, after some time of computer use) if_em.ko : 1027/3458/4485 mbufs in use (current/cache/total) 1024/2066/3090/25600 mbuf clusters in use (current/cache/total/max) 1024/1792 mbuf+clusters out of packet secondary zone in use (current/cache) 0/367/367/12800 4k (page size) jumbo clusters in use (current/cache/total/m= ax) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 2304K/6464K/8769K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines And here is the output with the new (non-working) if_em.ko : 1029/3456/4485 mbufs in use (current/cache/total) 1023/2067/3090/25600 mbuf clusters in use (current/cache/total/max) 1023/1793 mbuf+clusters out of packet secondary zone in use (current/cache) 0/367/367/12800 4k (page size) jumbo clusters in use (current/cache/total/m= ax) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 2303K/6466K/8769K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines I've got the "em0: Could not setup receive structures" messages with the new if_em.ko even in single user mode. No network connectivity. I tried removing all other network-related modules (vboxnet, ipfw...) and still have this problem (again, even when booting in single-user mode). My network card is "em0@pci0:0:25:0: class=3D0x020000 card=3D0x304b103c chip=3D0x10ef8086 rev=3D0x05 hdr=3D0x00". I'm using a stripped-down GENERIC amd64 kernel (no network, no scsi, no raid...), a nearly empty sysctl.conf and loader.conf (except module loading). I saw at the time of the commit that an MFC to 8-STABLE was planned, but I don't think it should happen so soon. Given that my network adapter was previously working well before the em driver update, can't this be considerd a serious regression ? Thanks, Olivier --=20 Olivier Smedts=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0 _ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 ASCII ribbon campaign ( ) e-mail: olivier@gid0.org=A0 =A0 =A0 =A0 - against HTML email & vCards=A0 X www: http://www.gid0.org=A0 =A0 - against proprietary attachments / \ =A0 "Il y a seulement 10 sortes de gens dans le monde : =A0 ceux qui comprennent le binaire, =A0 et ceux qui ne le comprennent pas."