em driver regression

Jack Vogel jfvogel at gmail.com
Thu Apr 8 19:17:03 UTC 2010


Try the code I just checked in, it puts in the CRC stripping, but also
tweaks the
TX code, this may resolve the watchdogs. Let me know.

Cheers,

Jack


On Thu, Apr 8, 2010 at 11:39 AM, Pyun YongHyeon <pyunyh at gmail.com> wrote:

> On Thu, Apr 08, 2010 at 11:27:10AM -0700, Jack Vogel wrote:
> > You know, I'm wondering if the so-called ALTQ fix, which makes the TX
> > start always queue is causing the problem on that side?
> >
>
> I'm not sure because I didn't configure ALTQ so it might be NOP for
> non-ALTQ case.
>
> > Jack
> >
> >
> > On Thu, Apr 8, 2010 at 11:22 AM, Jack Vogel <jfvogel at gmail.com> wrote:
> >
> > >
> > >
> > > On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon <pyunyh at gmail.com>
> wrote:
> > >
> > >> On Thu, Apr 08, 2010 at 10:46:22AM -0400, Mike Tancsa wrote:
> > >> >
> > >> > OK, some more data... It seems dhclient is getting upset as well
> > >> > since the updated driver
> > >> >
> > >> > Apr  8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to
> > >> > 255.255.255.255 port 67 interval 6
> > >> > Apr  8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with
> > >> > bytes received 332.
> > >> > Apr  8 10:28:38 ich10 dhclient[1383]: accepting packet with data
> > >> > after udp payload.
> > >> > Apr  8 10:28:38 ich10 dhclient[1383]: DHCPOFFER from 192.168.xx.1
> > >> > Apr  8 10:28:40 ich10 dhclient[1383]: DHCPREQUEST on em0 to
> > >> > 255.255.255.255 port 67
> > >> > Apr  8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with
> > >> > bytes received 332.
> > >>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > >>
> > >> Try this patch. It should fix the issue. It seems Jack forgot to
> > >> strip CRC bytes as old em(4) didn't strip it, probably to
> > >> workaround silicon bug of old em(4) controllers.
> > >>
> > >>
> > > Actually it did strip it, but its buried in the code in an obscure way,
> > > that's
> > > what I just realized by looking at the old code. having the hardware
> strip
> > > will be easier I think.
> > >
> > >
> > >> It seems there are also TX issues here. The system load is too high
> > >> and sometimes system is not responsive while TX is in progress.
> > >> Because I initiated TCP bulk transfers, TSO should reduce CPU load
> > >> a lot but it didn't so I guess it could also be related watchdog
> > >> timeouts you've seen. I'll see what can be done.
> > >>
> > >
> > > Will look at that as well.
> > >
> > > Thanks!
> > >
> > > Jack
> > >
> > >
>


More information about the freebsd-stable mailing list