Jeremy Fitzhardinge wrote:
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
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
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
I have another pair of softlockup patches in which I try to address:
* ignoring time stolen by hypervisors
* threads going to sleep tickless for long periods of time
I'm looking at the code now. Your solution is definately better :)
I could easy add a "global disable"
I have another pair of softlockup patches in which I try to address:
* ignoring time stolen by hypervisors
* threads going to sleep tickless for long periods of time
I'm looking at the code now. Your solution is definately better :)
I could easy add a global disable function,
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
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
Jeremy Fitzhardinge wrote:
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
> I could easy add a "global disable" function, which would allow long
> sysrq messages, and it would help Thilo with his long flash update freezes.
A "global disable" and "reenable" functions pair which works during irq
disabled,
would be a perfect solution for me. Thx Jeremy for your effort :)
Prarit Bhargava wrote:
> There are some situations when soft lockup warnings are expected in the
> kernel. For example, when doing an alt-sysrq-t on a large number of
> processes,
> the dump to console can take a long time and the tasklist_lock is held over
> that period. This results in a
Prarit Bhargava wrote:
There are some situations when soft lockup warnings are expected in the
kernel. For example, when doing an alt-sysrq-t on a large number of
processes,
the dump to console can take a long time and the tasklist_lock is held over
that period. This results in a bogus
I could easy add a global disable function, which would allow long
sysrq messages, and it would help Thilo with his long flash update freezes.
A global disable and reenable functions pair which works during irq
disabled,
would be a perfect solution for me. Thx Jeremy for your effort :)
Ciao
We've seen these here and had arrived at a similar patch. Extensive prints
on the console can take longer than the watchdog likes.
Acked-by: Rick Lindsley <[EMAIL PROTECTED]>
Rick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
We've seen these here and had arrived at a similar patch. Extensive prints
on the console can take longer than the watchdog likes.
Acked-by: Rick Lindsley [EMAIL PROTECTED]
Rick
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
14 matches
Mail list logo
