From owner-freebsd-net@FreeBSD.ORG Thu Mar 15 17:25:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8F05106564A; Thu, 15 Mar 2012 17:25:36 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 2EB118FC0C; Thu, 15 Mar 2012 17:25:36 +0000 (UTC) Received: by wibhj6 with SMTP id hj6so7512049wib.13 for ; Thu, 15 Mar 2012 10:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ItCkgefMntlG5wqq5DiLnTO5pfyzXD4ZECeg67NN23Y=; b=u85BkUG3zjaEuXBQZKpm+dFdQpRSSAiSNAtz5U2C41xtzKn0cTEazvee4HJAFL9+z2 ioOMhR+XkGoWnLFVJdUB6spmBMHg8EanKU41Jbs6Ocd1DJPsC3ohACKPv7OGxObqNrKu DVKzaOyD/2u94RyCRlEraMVXAF50hRFIFSENeUx+51HGNWZPtcUF/HumrHV7mJhYdddg zvNIsBw5+1Qx9H1U7c33KJu5qFkAC4esPzqMxcDka+6nnWwHv/ufHiPHsGDDC1hOn+VN W1kG9J1b6i8JePqRYU4sENFTSQ0O2JbI4KpkT32aiMq1cm6zeXbjmyDrwICIaqtHIGu2 wYuA== MIME-Version: 1.0 Received: by 10.180.94.33 with SMTP id cz1mr17670685wib.13.1331832329122; Thu, 15 Mar 2012 10:25:29 -0700 (PDT) Received: by 10.180.82.168 with HTTP; Thu, 15 Mar 2012 10:25:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 10:25:29 -0700 Message-ID: From: Jack Vogel To: Arnaud Lacombe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Juli Mallett , freebsd-net@freebsd.org Subject: Re: MSI-X + em(4) = Refresh mbufs: hdr dmamap load failure - 22 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 17:25:37 -0000 Opps, you're right, hadn't had my coffee and was thinking about igb :) Still have never seen this error before. Jack On Thu, Mar 15, 2012 at 9:45 AM, Arnaud Lacombe wrote: > Hi, > > On Thu, Mar 15, 2012 at 12:07 PM, Jack Vogel wrote: > > You have header split on?? I've not seen this before so something odd > > is going on. > > > AFAIK, you never implemented header-split on em(4), despite hardware > supporting it, so that question is pointless. > > - Arnaud > > > Jack > > > > > > On Thu, Mar 15, 2012 at 12:39 AM, Juli Mallett > wrote: > > > >> All, > >> > >> On both stable/9 and trunk I see that with one of either the 82571EB > >> or 82574L I am flooded with messages in the form of: > >> > >> Refresh mbufs: hdr dmamap load failure - 22 > >> > >> If I disable msix, then the messages go away. I am not sure why msix > >> vs. non-msix would matter in this case unless in the msix case there's > >> some kind of case of spurious interrupts causing em_rxeof to be called > >> without any packets available. If that happens then perhaps > >> e1000_rx_unrefreshed() is called when no buffers have been processed > >> and then em_refresh_mbufs wrongly refreshes the whole ring? > >> > >> This seems like it would be a problem because the > >> bus_dmamap_load_mbuf_sg code is called unconditionally, even when a > >> new mbuf isn't being allocated. In that case, the mapping already > >> exists. Wouldn't it be necessary to unload and then reload the mbuf? > >> So either it's a bug that em_refresh_mbufs is being called at all, or > >> it's naively reusing mbufs in a way that actually guarantees an error, > >> right? Also, in the case where it frees, only m_free is called =97 is > >> there never a case where that should be an m_freem? I can imagine > >> some, but they are likely impossible with the receive path of the > >> driver. (I don't know for sure because the receive path and the mbuf > >> refresh code keep changing and I've been unable to keep up.) > >> > >> I don't know which part it is, of course, because I don't know what > >> port it's coming from. Like three other printfs in the driver where > >> which device is being used matters tremendously, it uses a bare printf > >> and not a device_printf. I could modify the driver, but for now > >> disabling msix is easier than continuing to load new kernels to try to > >> debug the problem. > >> > >> Is anyone else seeing this? Has anyone further investigated the > >> problem? Is there a patch floating around and I just haven't found > >> the right search terms? > >> > >> Thanks in advance, > >> Juli. > >> > >> PS: Yes, I know this is kind of a crappy bug report, sorry. I've had > >> a limited amount of time to investigate so far, and don't want to > >> delay reporting it until I am able to get more time with the > >> problematic hardware. > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >> > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >