From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 32BABDDF16 for ; Sat, 9 Aug 2008 08:06:06 +1000 (EST) Subject: Re: Strange tg3 regression with UMP fw. link reporting From: Benjamin Herrenschmidt To: Matt Carlson In-Reply-To: <20080808184359.GB23249@HP-xw6200.broadcom.net> References: <1218180939.24157.332.camel@pasglop> <31233EB5-037E-4615-95C9-7C816E510752@kernel.crashing.org> <1218187111.24157.336.camel@pasglop> <20080808184359.GB23249@HP-xw6200.broadcom.net> Content-Type: text/plain Date: Sat, 09 Aug 2008 08:05:57 +1000 Message-Id: <1218233157.24157.343.camel@pasglop> Mime-Version: 1.0 Cc: linuxppc-dev list , Michael Chan , Nathan Lynch , netdev Reply-To: benh@kernel.crashing.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 2008-08-08 at 11:43 -0700, Matt Carlson wrote: > > Segher is right. The code should be 2.5 milliseconds but is actually > much longer. This fix is actually already in my patch queue and needs > to be sent upstream. > > We really shouldn't be displaying any error messages in the event of a > timeout though. Earlier versions of the UMP firmware did not support > the link update interface. The best thing the driver can do for all > cases is give the firmware a chance to service the event but continue > as if the event were serviced if it did not get an explicit ACK. But that means that the driver will continuously spin 2.5ms every timer tick or so ? Or do I miss something ? Could it be possible to count timeouts and if after N attempts at an ack, they all timed out, disable the feature completely ? Or is there a way to test the version of the firmware ? In any case, the fix should go into -stable as the problem is hurting 2.6.26. Also, should we consider updating the tg3 firmware on those machines ? Ben.