From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266204AbUGARzd (ORCPT ); Thu, 1 Jul 2004 13:55:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266209AbUGARzd (ORCPT ); Thu, 1 Jul 2004 13:55:33 -0400 Received: from mx1.redhat.com ([66.187.233.31]:59285 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S266204AbUGARz0 (ORCPT ); Thu, 1 Jul 2004 13:55:26 -0400 From: Jeff Moyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16612.20364.397802.306245@segfault.boston.redhat.com> Date: Thu, 1 Jul 2004 13:53:16 -0400 To: Matt Mackall Cc: linux-kernel@vger.kernel.org Subject: Re: netconsole hangs w/ alt-sysrq-t In-Reply-To: <20040701170512.GH25826@waste.org> References: <16527.47765.286783.249944@segfault.boston.redhat.com> <20040428142753.GE28459@waste.org> <16527.63123.869014.733258@segfault.boston.redhat.com> <16604.18881.850162.785970@segfault.boston.redhat.com> <20040625232711.GE25826@waste.org> <16608.12233.39964.940020@segfault.boston.redhat.com> <20040628151954.GH25826@waste.org> <16608.20014.220537.339589@segfault.boston.redhat.com> <20040701165201.GF25826@waste.org> <16612.16858.959279.469244@segfault.boston.redhat.com> <20040701170512.GH25826@waste.org> X-Mailer: VM 7.14 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid Reply-To: jmoyer@redhat.com X-PGP-KeyID: 1F78E1B4 X-PGP-CertKey: F6FE 280D 8293 F72C 65FD 5A58 1FF8 A7CA 1F78 E1B4 X-PCLoadLetter: What the f**k does that mean? Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org ==> Regarding Re: netconsole hangs w/ alt-sysrq-t; Matt Mackall adds: mpm> On Thu, Jul 01, 2004 at 12:54:50PM -0400, Jeff Moyer wrote: >> ==> Regarding Re: netconsole hangs w/ alt-sysrq-t; Matt Mackall >> adds: >> mpm> On Mon, Jun 28, 2004 at 12:58:22PM -0400, Jeff Moyer wrote: >> >> ==> Regarding Re: netconsole hangs w/ alt-sysrq-t; Matt Mackall >> >> adds: mpm> No, I think we get to this on the non-NAPI route as well. The ->poll mpm> check keeps us from filtering twice. >> >> I'll have to take your word for it on this one, as I can't find a way >> >> into this code for the non-napi case. Would anyone care to give an >> >> authoritative answer on this? >> mpm> I could be mistaken, but that's my recollection from last summer. mpm> Hopefully I'll have some spare cycles for this next week. >> >> One other thing we might consider is adding a call to >> >> touch_nmi_watchdog() to zap_completion_queue. >> mpm> Not sure how I feel about that yet. If we can't get out of the guts of mpm> netpoll in a timely fashion, then perhaps that's an indication that mpm> the watchdog should indeed fire. Describe the scenario where you think mpm> we should do this, please. >> Alt-Sysrq-t from the keyboard on a heavily-loaded UP system. mpm> Is it because we're spinning for too long waiting for skbs or is it mpm> just because sysrq-t takes that long to dump its guts? How does the mpm> watchdog get tickled in the sysrq-t over slow serial console case? mpm> In other words, would this better be done between dumps in the sysrq-t mpm> loop where we actually know we're making forward progress? Good point. I tend to center my thinking too much around netdump. You're right, if we're waiting too long for skb's, we probably should trigger the NMI watchdog. It also appears that show_state includes a call to touch_nmi_watchdog in its loop. -Jeff