Jeremy Fitzhardinge wrote:
Prarit Bhargava wrote:
I think that's a good idea -- I'll propose an add on patch to fix the
sysrq-t case ...
I'm working on this patch at the moment. I'm just wondering what
happens if you do a global re-enable while a CPU is locally disabled. I
think it won't matter; it will end up in the "enabled but need to update
timestamp" state, and the next time it gets a timer tick, it will simply
update the timestamp and carry on.
(This is relative to the other two softlockup patches, but modified
since I posted them.)
J
diff -r 4c81d8cafb67 drivers/char/sysrq.c
--- a/drivers/char/sysrq.c Tue Mar 27 01:16:07 2007 -0700
+++ b/drivers/char/sysrq.c Tue Mar 27 01:18:05 2007 -0700
@@ -408,6 +408,8 @@ void __handle_sysrq(int key, struct tty_
int i;
unsigned long flags;
+ softlockup_global_disable();
+
spin_lock_irqsave(&sysrq_key_table_lock, flags);
orig_log_level = console_loglevel;
console_loglevel = 7;
@@ -445,6 +447,8 @@ void __handle_sysrq(int key, struct tty_
console_loglevel = orig_log_level;
}
spin_unlock_irqrestore(&sysrq_key_table_lock, flags);
+
+ softlockup_global_enable();
I think that works -- I'll test it out on a big honkin' ia64 box ;)
Shouldn't you also do softlockup_disable/softlockup_enable instead of
touch_softlockup_watchdog? Why do we have both? I can't see why we
would have two exported methods to stop/reset the softlockup timer...
P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
