Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Mar 2012 17:37:29 -0700
From:      YongHyeon PYUN <pyunyh@gmail.com>
To:        Juli Mallett <jmallett@freebsd.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: MSI-X + em(4) = Refresh mbufs: hdr dmamap load failure - 22
Message-ID:  <20120316003729.GA3872@michelle.cdnetworks.com>
In-Reply-To: <CACVs6=9rTNAjEEdy7sBNEWPtoTdkx7eifZisQF5JTESAorQeJQ@mail.gmail.com>
References:  <CACVs6=9rTNAjEEdy7sBNEWPtoTdkx7eifZisQF5JTESAorQeJQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 15, 2012 at 12:39:30AM -0700, 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 ??? 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

Some time ago I also tried to debug low performance issue of 82574.
At that time I didn't encounter the issue you mentioned but I saw
spurious interrupts with MSI-X.  This issue is also mentioned in
82574 data sheet(7.4.5 Clearing Interrupt Causes).  However I
couldn't explain odd interrupt behavior(interrupt moderation, MSI
vs. MSI-X) of controller since the controller did not work as
described in data sheet.

> 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120316003729.GA3872>