Messages in this thread |  | | | Date | Tue, 27 Mar 2007 12:56:02 -0400 | | From | Prarit Bhargava <> | | Subject | Re: [PATCH]: Fix bogus softlockup warning with sysrq-t |
| |
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 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/
|  |