Date: Thu, 8 Apr 2010 11:39:00 -0700 From: Pyun YongHyeon <pyunyh@gmail.com> To: Jack Vogel <jfvogel@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: em driver regression Message-ID: <20100408183900.GJ5734@michelle.cdnetworks.com> In-Reply-To: <s2h2a41acea1004081127qac1d542dufcefbf5ec054e0ce@mail.gmail.com> References: <201004081313.o38DD4JM041821@lava.sentex.ca> <7.1.0.9.0.20100408091756.10652be0@sentex.net> <201004081446.o38EkU7h042296@lava.sentex.ca> <20100408181741.GI5734@michelle.cdnetworks.com> <g2q2a41acea1004081122ndec4e6a1mbac3f0f7fa11cc9c@mail.gmail.com> <s2h2a41acea1004081127qac1d542dufcefbf5ec054e0ce@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@gmail.com> wrote: > > > > > > > On Thu, Apr 8, 2010 at 11:17 AM, Pyun YongHyeon <pyunyh@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 > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100408183900.GJ5734>