I finally tracked down my keyboard problems under pre-patch-2.1.37-7.
It seems that hitting certain keys, like "scroll lock" and "numlock"
would lock up the keyboard. The keyboard could be "reset" remotely
using a "kbdrate" command (or otherwise remotely tickling the
keyboard), but after that, the keyboard would suddenly start freezing
on additional keys, like all the console-switching key combinations.
ANYWAY, it seems that the problem was the new "arch/i386/kernel/irq.[ch]"
code. At the end of "do_IRQ" in "irq.c", we have:
if (1) {
if (bh_active & bh_mask)
do_bottom_half();
}
This, potentially, will run the bottom halves with interrupts
*disabled*, and this throws the keyboard device into an uproar, since
it depends on getting (surprise!) keyboard interrupts to do its work.
The enclosed patch against pre-patch-2.1.37-7 appears to fix the
problem on my non-SMP kernel, but I have no idea if this is a "good"
fix, mostly because I don't understand any of these new-fangled SMP
locks and antilocks.
Thanks.
Kevin <buhr@stat.wisc.edu>
* * *
--- linux/arch/i386/kernel/irq.c 1997/05/12 16:05:01 1.1.1.2
+++ linux/arch/i386/kernel/irq.c 1997/05/14 04:12:45
@@ -561,8 +561,10 @@
* half handling or not..
*/
if (1) {
- if (bh_active & bh_mask)
+ if (bh_active & bh_mask) {
+ __sti();
do_bottom_half();
+ }
}
}