[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <4B4571D5.30002@majjas.com>
Date: Thu, 07 Jan 2010 00:32:05 -0500
From: Michael Breuer <mbreuer@...jas.com>
To: Stephen Hemminger <shemminger@...ux-foundation.org>
Cc: Jarek Poplawski <jarkao2@...il.com>,
David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
flyboy@...il.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH] af_packet: Don't use skb after dev_queue_xmit()
On 1/6/2010 11:53 PM, Stephen Hemminger wrote:
> On Wed, 06 Jan 2010 23:00:34 -0500
> Michael Breuer<mbreuer@...jas.com> wrote:
>
>
>> Changing MTU to 9000, everything basically breaks - Can't use X11 (local
>> or remote - get X11 screen after gdm login locally, but then goes back
>> to greeter; remote gets no greeter); ssh sessions hang; etc. This time I
>> was able to reset the MTU back to 1500 without a reboot - but I did have
>> to ifconfig eth0 down and then up. Looking at the sk98lin code, it looks
>> to me like they do a bit more work with existing buffers before
>> completing the MTU switch. Note that even doing this, X11 did not work
>> (it did with the old mtu change code). Tried changing to mtu 4500 - same
>> effect as 9000... but when I switched back to 1500, ksoftirqd started
>> spinning using 100% of one core.
>>
> The problem is that patch was enabling scatter-gather and checksum offload
> that won't work on EC_U hardware with 9K MTU. At least, it never worked
> for me when I tested it. So because of that it really doesn't change anything
> for the better on that chip version.
>
> What version chip is on that motherboard? Mine is:
> Yukon-2 EC Ultra chip revision 3
> which corresponds to B0 step.
>
> Another possibility is the PHY register which controls number of ticks
> of buffering. The default is zero, which gives the most buffering (good),
> but the firmware could be reprogramming it (bad). In general, the driver
> doesn't fiddle with bits that are already set correctly, because sometimes
> vendors need to tweak PCI timing in firmware/BIOS. It seems the firmware on this
> chip is just a bunch of register setups done on power on.
>
Also - I'm seeing a huge number of dropped packets (RX) 200-300/second.
Probably why this is so slow.
Current ifconfig:
eth0 Link encap:Ethernet HWaddr 00:26:18:00:1C:3B
inet addr:10.0.0.1 Bcast:10.0.0.255 Mask:255.255.255.0
inet6 addr: fe80::226:18ff:fe00:1c3b/64 Scope:Link
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:26647536 errors:0 dropped:517884 overruns:0 frame:0
TX packets:12112780 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:38960063319 (36.2 GiB) TX bytes:1889879762 (1.7 GiB)
Interrupt:18
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists