The changes to igb were to add IPV6 support which previously was only in
ixgbe, the
transmit path code came from that code base, we did not see this issue in
testing. Its
not a simple matter of a few lines of code, I think we need to go forward
not back... I'll
look at the code.


On Fri, Jan 10, 2014 at 2:35 AM, Gleb Smirnoff <> wrote:

>   Yonghyeon,
> On Fri, Jan 10, 2014 at 10:21:14AM +0900, Yonghyeon PYUN wrote:
> Y> > I experience some troubles with the igb device driver on FreeBSD
> 10-RC4.
> Y> >
> Y> > The kernel make a pagefault in the igb_tx_ctx_setup function when
> accessing to
> Y> > a IPv6 header.
> Y> >
> Y> > The network configuration is the following:
> Y> >  - box acting as an IPv6 router
> Y> >  - one interface with an IPv6 (igb0)
> Y> >  - another interface with a vlan, and IPv6 on it (vlan0 on igb1)
> Y> >
> Y> > Vlan Hardware tagging is set on both interfaces.
> Y> >
> Y> > The packet that cause the crash come from igb0 and go to vlan0.
> Y> >
> Y> > After investigation, i see that the mbuf is split in two. The first
> one carry
> Y> > the ethernet header, the second, the IPv6 header and data payload.
> Y> >
> Y> > The split is due to the "m_copy" done in ip6_forward, that make the
> mbuf not
> Y> > writable and the "M_PREPEND" in ether_output that insert the new mbuf
> before
> Y> > the original one.
> Y> >
> Y> > The kernel crashes only if the newly allocated mbuf is at the end of
> a memory
> Y> > page, and no page is available after this one. So, it's extremly rare.
> Y> >
> Y> > I inserted a "KASSERT" into the function (see attached patch) to
> check this
> Y> > behavior, and it raises on every IPv6 forwarded packet to the vlan.
> The
> Y> > problem disapear if i remove hardware tagging.
> Y> >
> Y> > In the commit 256200, i see that pullups has been removed. May it be
> related ?
> Y>
> Y> I think I introduced the header parsing code to meet controller
> Y> requirement in em(4) and Jack borrowed that code in the past but it
> Y> seems it was removed in r256200.  It seems igb_tx_ctx_setup()
> Y> assumes it can access ethernet/IP/TCP/UDP headers in the first mbuf
> Y> of the chain.
> Y> This looks wrong to me.
> Can you please restore the important code in head ASAP? Although crashes
> happen
> only when the mbuf is last in a page and page isn't mapped, we read thrash
> from
> next allocation on almost every packet.
> --
> Totus tuus, Glebius.
_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to