From owner-freebsd-current@FreeBSD.ORG Wed Apr 27 15:44:51 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 CBA01106566C for ; Wed, 27 Apr 2011 15:44:51 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7D06E8FC0C for ; Wed, 27 Apr 2011 15:44:51 +0000 (UTC) Received: by vxc34 with SMTP id 34so1860360vxc.13 for ; Wed, 27 Apr 2011 08:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bs11DK7+IA9skbH7hpCEq71teDfzbJp4pMFXUdhfIf0=; b=mZ+wYElzw1bC6F7Eevk+ybxymKS5uLuSMRswILUAI1jAh4lFtneMYTMsF8sllRfP01 cAfemsPu/4BBll0dQlyKya8jcxxUVWYqdwoRWvAjpcqFW/y/sJsRFDu8etm4l00XOflS ZuCP77kEAVRhIu9imQvQuuvZQA+ajiLZzVyuk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ul5AtWSimNf5rnvOhs8xTxhFDEkLlFphVAx+Dl8vo0ADvec8LAR83FYuy3iOXPBCeJ C2ZbLjqRoX84gQDxCml/WvU95g+CncMoAi35/tCT14c1hV0LYI/c3G4PR+Pyxlwt5ysA jkR9J0as+rVEFJ/zlbdXLrXXcEN6ux1qFoEkI= MIME-Version: 1.0 Received: by 10.52.67.73 with SMTP id l9mr3248664vdt.287.1303919090526; Wed, 27 Apr 2011 08:44:50 -0700 (PDT) Received: by 10.52.167.67 with HTTP; Wed, 27 Apr 2011 08:44:50 -0700 (PDT) In-Reply-To: References: <4D94A354.9080903@sentex.net> Date: Wed, 27 Apr 2011 08:44:50 -0700 Message-ID: From: Jack Vogel To: Olivier Smedts Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 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 15:44:51 -0000 If you get "cannot setup receive structures" you cannot go on and try to use the thing :) It means you have inadequate mbuf clusters to setup your receive side, you simply have to increase it and reload the driver. Jack On Wed, Apr 27, 2011 at 5:39 AM, Olivier Smedts wrote: > 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 > think > > 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 > them > > 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/max) > 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/max) > 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=0x020000 > card=0x304b103c chip=0x10ef8086 rev=0x05 hdr=0x00". 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 > > -- > Olivier Smedts _ > ASCII ribbon campaign ( ) > e-mail: olivier@gid0.org - against HTML email & vCards X > www: http://www.gid0.org - against proprietary attachments / \ > > "Il y a seulement 10 sortes de gens dans le monde : > ceux qui comprennent le binaire, > et ceux qui ne le comprennent pas." >