Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753148Ab2K1Ibg (ORCPT ); Wed, 28 Nov 2012 03:31:36 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:27082 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752798Ab2K1Ibf (ORCPT ); Wed, 28 Nov 2012 03:31:35 -0500 Message-ID: <50B5CBD2.5020804@oracle.com> Date: Wed, 28 Nov 2012 16:31:14 +0800 From: Joe Jin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Ben Hutchings CC: "Fujinaka, Todd" , Mary Mcgrath , "netdev@vger.kernel.org" , "e1000-devel@lists.sf.net" , "linux-kernel@vger.kernel.org" , linux-pci Subject: Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang References: <509B5038.8090304@oracle.com> <061C8A8601E8EE4CA8D8FD6990CEA89133487884@ORSMSX102.amr.corp.intel.com> <50A30656.6090508@oracle.com> <061C8A8601E8EE4CA8D8FD6990CEA8913348B105@ORSMSX102.amr.corp.intel.com> <50A43828.6000702@oracle.com> <061C8A8601E8EE4CA8D8FD6990CEA8913349A0B4@ORSMSX102.amr.corp.intel.com> <50A9C5CC.1030300@oracle.com> <061C8A8601E8EE4CA8D8FD6990CEA8913349EB41@ORSMSX102.amr.corp.intel.com> <50AB8471.7080607@oracle.com> <9B4A1B1917080E46B64F07F2989DADD62F2D62D6@ORSMSX102.amr.corp.intel.com> <50B41077.3080009@oracle.com> <9B4A1B1917080E46B64F07F2989DADD62F2D8070@ORSMSX102.amr.corp.intel.com> <1354039840.2701.14.camel@bwh-desktop.uk.solarflarecom.com> In-Reply-To: <1354039840.2701.14.camel@bwh-desktop.uk.solarflarecom.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1698 Lines: 40 On 11/28/12 02:10, Ben Hutchings wrote: > On Tue, 2012-11-27 at 17:32 +0000, Fujinaka, Todd wrote: >> Forgive me if I'm being too repetitious as I think some of this has >> been mentioned in the past. >> >> We (and by we I mean the Ethernet part and driver) can only change the >> advertised availability of a larger MaxPayloadSize. The size is >> negotiated by both sides of the link when the link is established. The >> driver should not change the size of the link as it would be poking at >> registers outside of its scope and is controlled by the upstream >> bridge (not us). > [...] > > MaxPayloadSize (MPS) is not negotiated between devices but is programmed > by the system firmware (at least for devices present at boot - the > kernel may be responsible in case of hotplug). You can use the kernel > parameter 'pci=pcie_bus_perf' (or one of several others) to set a policy > that overrides this, but no policy will allow setting MPS above the > device's MaxPayloadSizeSupported (MPSS). > Ben, Unfortunately I'm using 3.0.x kernel and this is not included in the kernel. So I'm trying to use ethtool modify it from eeprom to see if help or no. Todd, I'll review all MaxPayload for all devices, but need to say if it mismatch, customer could not modify it from BIOS for there was not entry at there, to test it, we have to find how to verify if this is the root cause, so still need to find the offset in eeprom. Thanks in advance, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/