On Fri, Jan 10, 2014 at 02:35:29PM +0400, 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. >
It seems other Intel ethernet drivers except em(4) have similar issues. I didn't check recent Intel controllers/drivers for long time so I don't know details on hardware requirements of offloading. Since Jack is very responsive and has hardwares to verify, he would be more appropriate person to handle these issues. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"