Received: with ECARTIS (v1.0.0; list netdev); Wed, 22 Dec 2004 09:18:28 -0800 (PST) Received: from waste.org (waste.org [216.27.176.166]) by oss.sgi.com (8.13.0/8.13.0) with ESMTP id iBMHI08w025806 for ; Wed, 22 Dec 2004 09:18:20 -0800 Received: from waste.org (localhost [127.0.0.1]) by waste.org (8.12.3/8.12.3/Debian-7.1) with ESMTP id iBMHIbkC025405; Wed, 22 Dec 2004 11:18:37 -0600 Received: (from oxymoron@localhost) by waste.org (8.12.3/8.12.3/Debian-7.1) id iBMHIa9Z025402; Wed, 22 Dec 2004 11:18:36 -0600 Date: Wed, 22 Dec 2004 09:18:36 -0800 From: Matt Mackall To: Patrick McHardy Cc: Francois Romieu , Mark Broadbent , linux-kernel@vger.kernel.org, netdev@oss.sgi.com Subject: Re: Lockup with 2.6.9-ac15 related to netconsole Message-ID: <20041222171836.GL5974@waste.org> References: <52121.192.102.214.6.1103624620.squirrel@webmail.wetlettuce.com> <20041221123727.GA13606@electric-eye.fr.zoreil.com> <49295.192.102.214.6.1103635762.squirrel@webmail.wetlettuce.com> <20041221204853.GA20869@electric-eye.fr.zoreil.com> <20041221212737.GK5974@waste.org> <20041221225831.GA20910@electric-eye.fr.zoreil.com> <41C93FAB.9090708@trash.net> <41C9525F.4070805@trash.net> <20041222123940.GA4241@electric-eye.fr.zoreil.com> <41C98B75.9020802@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41C98B75.9020802@trash.net> User-Agent: Mutt/1.3.28i X-Virus-Scanned: ClamAV 0.80/627/Sun Dec 12 11:53:11 2004 clamav-milter version 0.80j on 127.0.0.1 X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-archive-position: 12991 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: mpm@selenic.com Precedence: bulk X-list: netdev On Wed, Dec 22, 2004 at 03:57:57PM +0100, Patrick McHardy wrote: > >Of course the patch is completely ugly and violates any layering > >principle one could think of. It was not submitted for inclusion :o) > > Sure, but I think we should have a short-term workaround until > a better solution has been invented. Maybe dropping the packets > would be best for now, it only affects printks issued in paths > starting at qdisc_restart (-> hard_start_xmit -> ...). Queueing > the packets might also cause reordering since not all packets > are queued. When I mentioned queueing, I was thinking of a netpoll-private queue that would be hooked to a softirq or some such so that it would be pushed out as soon as possible. Dropping may be the better approach as queueing throws away netpoll's immediacy and ordering properties. And getting netpoll _more_ tangled in the net stack mechanics is definitely a step in the wrong direction. More generally, I'm tempted to add some warn_on style functionality so that printks in such troublesome paths can be lifted out. -- Mathematics is the supreme nostalgia of our time.