Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751771Ab0AGFLM (ORCPT ); Thu, 7 Jan 2010 00:11:12 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750785Ab0AGFLK (ORCPT ); Thu, 7 Jan 2010 00:11:10 -0500 Received: from mta4.srv.hcvlny.cv.net ([167.206.4.199]:63115 "EHLO mta4.srv.hcvlny.cv.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750776Ab0AGFLJ (ORCPT ); Thu, 7 Jan 2010 00:11:09 -0500 Date: Thu, 07 Jan 2010 00:10:24 -0500 From: Michael Breuer Subject: Re: [PATCH] af_packet: Don't use skb after dev_queue_xmit() In-reply-to: <20100106205343.5460d658@nehalam> To: Stephen Hemminger Cc: Jarek Poplawski , David Miller , akpm@linux-foundation.org, flyboy@gmail.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Message-id: <4B456CC0.1000506@majjas.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT References: <20100105230746.GA6612@del.dom.local> <4B43F72C.9090004@majjas.com> <20100106072208.GA6711@ff.dom.local> <4B44E952.5000804@majjas.com> <20100106131044.25b4e500@nehalam> <4B451C31.3000309@majjas.com> <4B454A16.3030909@majjas.com> <4B455C62.6030504@majjas.com> <20100106205343.5460d658@nehalam> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b2pre Thunderbird/3.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5814 Lines: 112 On 1/6/2010 11:53 PM, Stephen Hemminger wrote: > On Wed, 06 Jan 2010 23:00:34 -0500 > Michael Breuer 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. > So at this point, things are working as mentioned - but really slow... at least an order of magnitude slower than with the other set of patches. The other set also generated errors and was not stable :( But, that set worked with mtu=9000, this set doesn't seem to work with anything over 1500. The slowdown may also be (based on earlier testing) attributable to Jarek's alternative #2 patch. As to the chip, I *think* we have the same chip - I'm including lspci -vv - perhaps there is something different. 06:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 14) Subsystem: Giga-byte Technology Device e000 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-