[stable] [patch 00/21] 2.6.19-stable review

[stable] [patch 00/21] 2.6.19-stable review

Post by Greg K » Fri, 02 Mar 2007 06:40:15



Documentation/stable_kernel_rules.txt

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to XXXX@XXXXX.COM
More majordomo info at http://www.yqcomputer.com/
Please read the FAQ at http://www.yqcomputer.com/
 
 
 

[stable] [patch 00/21] 2.6.19-stable review

Post by ebieder » Fri, 02 Mar 2007 08:40:08

reg KH < XXXX@XXXXX.COM > writes:



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 < XXXX@XXXXX.COM >
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 < XXXX@XXXXX.COM >
Signed-off-by: Andi Kleen < XXXX@XXXXX.COM >
Cc: "Luigi Genoni" < XXXX@XXXXX.COM >
Cc: Andi Kleen < XXXX@XXXXX.COM >
Signed-off-by: Andrew Morton < XXXX@XXXXX.COM >

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 <asm/uaccess.h>
#include <asm/io_apic.h>
#include <asm/idle.h>
+#include <asm/smp.h>

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 XXXX@XXXXX.COM
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/