Date: Thu, 8 Apr 2010 11:27:10 -0700 From: Jack Vogel <jfvogel@gmail.com> To: pyunyh@gmail.com Cc: freebsd-stable@freebsd.org Subject: Re: em driver regression Message-ID: <s2h2a41acea1004081127qac1d542dufcefbf5ec054e0ce@mail.gmail.com> In-Reply-To: <g2q2a41acea1004081122ndec4e6a1mbac3f0f7fa11cc9c@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? 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?s2h2a41acea1004081127qac1d542dufcefbf5ec054e0ce>