Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752236AbXB1XaF (ORCPT ); Wed, 28 Feb 2007 18:30:05 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752237AbXB1XaE (ORCPT ); Wed, 28 Feb 2007 18:30:04 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:41611 "EHLO ebiederm.dsl.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752236AbXB1XaB (ORCPT ); Wed, 28 Feb 2007 18:30:01 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Greg KH Cc: Zwane Mwaikambo , "Theodore Ts'o" , Justin Forbes , Andi Kleen , Chris Wedgwood , linux-kernel@vger.kernel.org, Randy Dunlap , Chuck Wolber , Chuck Ebbert , Dave Jones , Andrew Morton , Michael Krufky , Linus Torvalds , stable@kernel.org, alan@lxorguk.ukuu.org.uk Subject: Re: [stable] [patch 00/21] 2.6.19-stable review References: <20070221013619.GA30227@kroah.com> <45DC9E1D.40805@redhat.com> <20070221114737.a09be761.akpm@linux-foundation.org> <20070228195255.GA7978@kroah.com> Date: Wed, 28 Feb 2007 16:25:07 -0700 In-Reply-To: <20070228195255.GA7978@kroah.com> (Greg KH's message of "Wed, 28 Feb 2007 11:52:55 -0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3347 Lines: 92 Greg KH writes: > On Wed, Feb 28, 2007 at 05:28:27AM -0700, Eric W. Biederman wrote: >> >> What are the rules that are supposed to govern backports to stable >> trees these days anyway? > > Documentation/stable_kernel_rules.txt Ok if that is really what we are going with, the this silly patch isn't simple enough for a backport. There used to other rules to the effect the patch must be merged in mainline, and we only backport to one kernel revision. I think it fails the 100 lines with context test. The meaning of obviously correct is a little bit nebulous. But if something is obvious multiple people can easily understand what is going on. I haven't gotten any feedback that has said yes I see what you are doing on the mentioned patch. I'm really not certain how this patch got seriously proposed then. I guess it was the serious of the issues of peoples boxes falling over. I guess somewhere I got the rules for weird vendor trees confused with our stable branches. The relaxed stable branch rules probably did it to me. So the best we can do is the commit below for a backport. It doesn't fix the issue but it generally keeps the machines from falling over. p.s. The copy below is whitespace damaged because I just cut and pasted it into this email. commit 2fb12a9bca5ad9aa6dcd2c639b4a7656a8843ef8 Author: Eric W. Biederman Date: Tue Feb 13 13:26:25 2007 +0100 [PATCH] x86-64: survive having no irq mapping for a vector Occasionally the kernel has bugs that result in no irq being found for a given cpu vector. If we acknowledge the irq the system has a good chance of continuing even though we dropped an irq message. If we continue to simply print a message and not acknowledge the irq the system is likely to become non-responsive shortly there after. AK: Fixed compilation for UP kernels Signed-off-by: Eric W. Biederman Signed-off-by: Andi Kleen Cc: "Luigi Genoni" Cc: Andi Kleen Signed-off-by: Andrew Morton diff --git a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c index 0c06af6..3bc30d2 100644 --- a/arch/x86_64/kernel/irq.c +++ b/arch/x86_64/kernel/irq.c @@ -18,6 +18,7 @@ #include #include #include +#include atomic_t irq_err_count; @@ -120,9 +121,14 @@ asmlinkage unsigned int do_IRQ(struct pt_regs *regs) if (likely(irq < NR_IRQS)) generic_handle_irq(irq); - else if (printk_ratelimit()) - printk(KERN_EMERG "%s: %d.%d No irq handler for vector\n", - __func__, smp_processor_id(), vector); + else { + if (!disable_apic) + ack_APIC_irq(); + + if (printk_ratelimit()) + printk(KERN_EMERG "%s: %d.%d No irq handler for vector\n", + __func__, smp_processor_id(), vector); + } irq_exit(); - 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/