From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932188AbZHYVy6 (ORCPT ); Tue, 25 Aug 2009 17:54:58 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754992AbZHYVy5 (ORCPT ); Tue, 25 Aug 2009 17:54:57 -0400 Received: from emroute1.ornl.gov ([160.91.4.119]:60710 "EHLO emroute1.ornl.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754460AbZHYVy4 (ORCPT ); Tue, 25 Aug 2009 17:54:56 -0400 X-Greylist: delayed 500 seconds by postgrey-1.27 at vger.kernel.org; Tue, 25 Aug 2009 17:54:56 EDT Date: Tue, 25 Aug 2009 17:54:56 -0400 From: David Dillow Subject: Re: [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts In-reply-to: To: "Eric W. Biederman" Cc: Michael Riepe , Michael Buesch , Francois Romieu , Rui Santos , Michael =?ISO-8859-1?Q?B=FCker?= , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Message-id: <1251237296.9607.42.camel@lap75545.ornl.gov> MIME-version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-2.fc10) Content-type: text/plain Content-transfer-encoding: 7bit References: <200903041828.49972.m.bueker@berlin.de> <1242001754.4093.12.camel@obelisk.thedillows.org> <200905112248.44868.mb@bu3sch.de> <200905112310.08534.mb@bu3sch.de> <1242077392.3716.15.camel@lap75545.ornl.gov> <4A09DC3E.2080807@googlemail.com> <1242268709.4979.7.camel@obelisk.thedillows.org> <4A0C6504.8000704@googlemail.com> <1242328457.32579.12.camel@lap75545.ornl.gov> <4A0C7443.1010000@googlemail.com> <1243042174.3580.23.camel@obelisk.thedillows.org> <1250895567.23419.1.camel@obelisk.thedillows.org> <1250897657.23419.5.camel@obelisk.thedillows.org> <1250973787.3582.14.camel@obelisk.thedillows.org> <1251169150.4023.11.camel@obelisk.thedillows.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2009-08-25 at 14:37 -0700, Eric W. Biederman wrote: > David Dillow writes: > > Here's a possible patch to mask the NAPI events while we're running in > > NAPI mode. I'm not sure it is going to help, since the intr_mask was > > 0xffff when you hit the loop guard, so I left it in for now. > > Ok. I now get what your patch was trying to do and that does look like > a reasonable test. > > I prefer: > while ((status != 0xffff) && (status & tp->intr_mask)) I had thought of going that route first, but if you have any interrupt event sources set, you want to enter the loop at least once to clear them, otherwise you never see another MSI interrupt. If the masking is the way things play out, then I'd put it where I had it and put in a comment as to why it is there. > The presence of TxDescUnavail suggests as is usually the case > that the interrupt status bits are independent of which interrupts > are actually enabled to fire. Yes, but I seem to recall the MSI's edge detection being especially oddly done -- I did tests with various masks and using the ability to have it generate an interrupt on user demand, and IIRC it was handled before the mask was applied, so we really did care about the events that were active -- but I may misremember. > I will take a moment and give that a try. > > I still like the idea of masking everything having poll do all > of the work and then unmasking everything. That seems a little less > fragile to me. I wouldn't object if you did it, but I don't have time for it right now. And it may make Francois's life harder when he does his periodic sweep of the vendor driver, looking for differences.