request for MFC of em/igb drivers
Chris Peiffer
bsdlists at cabstand.com
Thu Nov 18 16:30:09 UTC 2010
Thank you Jack, and thank you Eugene. I will integrate that NULL-check
into my tree immediately.
On Wed, Nov 17, 2010 at 09:39:14AM -0800, Jack Vogel wrote:
> Yes, everyone, I plan on updating all the drivers, there has been no
> activity
> because I've tracking down a couple bugs that are tough, involving days
> of testing to reproduce. I know we're getting close and I appreciate any
> reports like this before.
>
> Stay tuned....
>
> Jack
>
>
> On Wed, Nov 17, 2010 at 5:22 AM, Vlad Galu <dudu at dudu.ro> wrote:
>
> > On Wed, Nov 17, 2010 at 1:54 PM, Eugene Grosbein <eugen at grosbein.pp.ru>
> > wrote:
> > > On 17.11.2010 13:04, Chris Peiffer wrote:
> > >>
> > >> Hi,
> > >>
> > >> I've been watching the traffic here over the last few months relating
> > >> to the em and igb Intel ethernet drivers. It seems like there's a big
> > >> consensus that HEAD has some good new fixes.
> > >>
> > >> Looking at this:
> > >>
> > >> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/if_em.c
> > >>
> > >> There's a pretty big commit to HEAD in rev 1.58 on Sep 27 that's
> > >> marked "MFC: a week" but it doesn't look like anything's been MFC'd
> > >> since. (And several other revisions that look more experimental have
> > >> since gone into HEAD.)
> > >>
> > >> We've been seeing some weird issues with em devices under high load
> > >> and if these changes in 1.58 are ready for STABLE we'd love to test
> > >> them live.
> > >>
> > >> So this is a beg... if the relevant committers are out here, can that
> > >> MFC go through soon? Or if it can't, or I'm reading the logs wrong,
> > >> please explain.
> > >>
> > >> Thanks in advance.
> > >
> > > Indeed, in RELENG_8 em(4) is not useable for us because of two flaws:
> > >
> > > 1. It panices system due to NULL pointers dereference.
> > > It needs the following patch taken from CURRENT's igb(4):
> > >
> > > --- if_em.c.orig 2010-11-02 15:45:56.000000000 +0600
> > > +++ if_em.c 2010-11-08 14:24:46.000000000 +0600
> > > @@ -4181,9 +4181,11 @@
> > > ifp->if_ierrors++;
> > > /* Reuse loaded DMA map and just update mbuf chain
> > */
> > > mp = rxr->rx_buffers[i].m_head;
> > > + if(mp) {
> > > mp->m_len = mp->m_pkthdr.len = MCLBYTES;
> > > mp->m_data = mp->m_ext.ext_buf;
> > > mp->m_next = NULL;
> > > + }
> > > if (adapter->max_frame_size <=
> > > (MCLBYTES - ETHER_ALIGN))
> > > m_adj(mp, ETHER_ALIGN);
> > >
> > > igb(4) in RELENG_8 has not this fix too and there is a PR:
> > > http://www.freebsd.org/cgi/query-pr.cgi?pr=150920
> > >
> > > 2. It makes physical link down/up for every vlan creation/deletion
> > > that leads to 3 seconds of service interruption and
> > > down/up events for all other vlans based on same parent interface.
> > > It needs the following patch that's already present in CURRENT
> > > but not in RELENG_8:
> > >
> > > @@ -4342,7 +4344,8 @@
> > > em_shadow_vfta[index] |= (1 << bit);
> > > ++adapter->num_vlans;
> > > /* Re-init to load the changes */
> > > - em_init(adapter);
> > > + if (ifp->if_capenable & IFCAP_VLAN_HWFILTER)
> > > + em_init(adapter);
> > > }
> > >
> > > /*
> > > @@ -4366,7 +4369,8 @@
> > > em_shadow_vfta[index] &= ~(1 << bit);
> > > --adapter->num_vlans;
> > > /* Re-init to load the changes */
> > > - em_init(adapter);
> > > + if (ifp->if_capenable & IFCAP_VLAN_HWFILTER)
> > > + em_init(adapter);
> > > }
> > >
> > > static void
> > > _______________________________________________
> > > freebsd-net at freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> > >
> >
> > Any plans for bringing in version 2.2.3 of ixgbe(4)?
> >
> >
> > --
> > Good, fast & cheap. Pick any two.
> > _______________________________________________
> > freebsd-net at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
> >
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
More information about the freebsd-net
mailing list