Date: Wed, 15 Jan 2014 10:34 +0100 From: Alexandre Martins <alexandre.martins@netasq.com> To: Eric Joyner <ricera10@gmail.com> Cc: pyunyh@gmail.com, damien.deville@netasq.com, freebsd-current@freebsd.org, fabien.thomas@netasq.com, Gleb Smirnoff <glebius@freebsd.org>, Jack F Vogel <jfv@freebsd.org> Subject: Re: FreeBSD 10-RC4: Got crash in igb driver Message-ID: <2055921.6VO2ozmCaJ@pc-alex> In-Reply-To: <CA%2Bb0zg-tpzLve_mkuq7%2BfG1f-A9DgeKf8vqBpbrAK33s5Y%2B2fQ@mail.gmail.com> References: <48005124.ny58tnLn4d@pc-alex> <20140113021018.GA3500@michelle.cdnetworks.com> <CA%2Bb0zg-tpzLve_mkuq7%2BfG1f-A9DgeKf8vqBpbrAK33s5Y%2B2fQ@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] I have some compillation issues : ../../../dev/e1000/if_igb.c: In function 'igb_mq_start_locked': ../../../dev/e1000/if_igb.c:3936: warning: 'poff' may be used uninitialized in this function ../../../dev/e1000/if_igb.c:3936: note: 'poff' was declared here ../../../dev/e1000/if_igb.c:3936: warning: 'ip_hlen' may be used uninitialized in this function ../../../dev/e1000/if_igb.c:3936: note: 'ip_hlen' was declared here But this fix the crash. However, I have now a copy made of all ipv6 forwarded packet in igb_pullup_headers. It will be nice to m_free the copy of the packet made in ip6_forward before calling nd6_output function. It will put back the packet writable and avoid (in most cases) the copy. I have no time this week to check performance of this new driver version. I'll try to make that Monday. Thank you for this fix Le mardi 14 janvier 2014 14:22:43 Eric Joyner a crit : > All, > > I work with Jack on FreeBSD network drivers, and we have a patch that we > think might fix this problem. It re-implements the header pull-up code that > was in the driver pre-2.4.0, but with IPv6 support. Alexandre, could you > apply this patch to the igb version in HEAD and try it out on your network? > We can't replicate your setup here. > > If it solves your problem, then the next step would be to port the patch to > the ixgbe driver since, as Yonghyeon noted, it looks like that driver will > encounter the same problem. We could then modify em to add IPv6 offload > support as well. > > Thanks, > > --- > - Eric Joyner > > 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-unsubscribe@freebsd.org" -- Alexandre Martins NETASQ -- We secure IT [-- Attachment #2 --] 0 *H 01 0 + 0 *H 00 pƱHkl40 *H 01 0 UFR1 0 UNord10UVilleneuve d'Ascq1.0,U %NETASQ - Secure Internet Connectivity1'0%U NETASQ Certification Authority0 130215154957Z 140215154957Z01 0 UFR1 0 UNord10UVilleneuve d'Ascq1.0,U %NETASQ - Secure Internet Connectivity1'0%U NETASQ Certification Authority10UAlexandre MARTINS1+0) *H alexandre.martins@netasq.com0"0 *H 0 ?>Yx p6<N`w n^_WkL0_0\62m=@3iAş% һ]Ԁ9/MKaFPzpAs=tL[*a:h % %rwQ BGX 2= D![&Ǟ\4$6V` M ?#- hgDͳ gUGI&θPFߜ/&Oǰn3Q 00 U !`ldVz60 U #0'* D:sj %0 U 0 0U 0'U 0 alexandre.martins@netasq.com0 `HB0 U %0++0 *H IR$n*ws&jE2BmzH!ᆫw7#UA>GMˢ9F%c L߰X.^ C1σYߦoRp-֧cdL1wN/4^iWi (Heܧğ@Y6 yy;u5SbuIQMHm"g ii6 VtS_ه#!P5B?K M:O ]е|K-{@ k1R0N001 0 UFR1 0 UNord10UVilleneuve d'Ascq1.0,U %NETASQ - Secure Internet Connectivity1'0%U NETASQ Certification Authority pƱHkl40 + 0 *H 1 *H 0 *H 1 140115093400Z0# *H 1Ty=ӱ%q,U0( *H 100 `He0 *H 0 *H 泭ԛG5x.1 57&]/1ah [8B+"6e^ TԽ~~\ƠN,22 Rv8gQ>¿ɡ6 InG>kg}odn^B Q%v٬3)ݪip}(Od6m D2wfl) ht5"⫅;9%p}ۃR8Nx1ܥ(CSRRDc Ik4L<zo-|Q&home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2055921.6VO2ozmCaJ>