They probably didn't really impact your problem, and the thing is just
timing-dependent. The patches changed timings, or you had a slightly
different bootup sequence or something.
Then some other unrelated changes in 2.1.121 made the problem show up
again.
>I am running out of ideas as to why this is happening.
Can you test this small patch? The 2.1.120 patch made a lot of the IRQ
status handling more strict, because under certain circumstances people
got endless interrupt storms that used up a lot of CPU. However, having
reviewed the code I found two places where I made it _too_ strict. They
usually shouldn't make any difference, but I can certainly see potential
impact when it lost some information about pending interrupt handling..
Linus
-----
diff -u --recursive --new-file penguin/linux/arch/i386/kernel/irq.c linux/arch/i386/kernel/irq.c
--- penguin/linux/arch/i386/kernel/irq.c Wed Sep 9 23:28:00 1998
+++ linux/arch/i386/kernel/irq.c Wed Sep 9 23:27:42 1998
@@ -699,7 +699,7 @@
* install a handler for this interrupt (make irq autodetection
* work by just looking at the status field for the irq)
*/
- irq_desc[irq].status = 0;
+ irq_desc[irq].status &= ~(IRQ_DISABLED | IRQ_INPROGRESS);
irq_desc[irq].handler->enable(irq);
spin_unlock_irqrestore(&irq_controller_lock, flags);
}
@@ -785,7 +785,6 @@
*p = new;
if (!shared) {
- irq_desc[irq].status = 0;
#ifdef __SMP__
if (IO_APIC_IRQ(irq)) {
/*
@@ -796,10 +795,11 @@
if (irq < 16) {
disable_8259A_irq(irq);
if (i8259A_irq_pending(irq))
- irq_desc[irq].status = IRQ_PENDING;
+ irq_desc[irq].status |= IRQ_PENDING;
}
}
#endif
+ irq_desc[irq].status &= ~(IRQ_DISABLED | IRQ_INPROGRESS);
irq_desc[irq].handler->enable(irq);
}
spin_unlock_irqrestore(&irq_controller_lock,flags);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html