em driver regression

[Jack Vogel]

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 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
>
>