On Wed, 22 Jul 2020 12:49:52 +0200
Greg KH wrote:
> On Wed, Jul 22, 2020 at 05:26:09PM +0800, Yue Hu wrote:
> > From: Yue Hu
> >
> > Currently, sysrq_key_table[] has 10 slots for same interface to change
> > console loglevel. No specific purpose to do that. Let's use only one slot
> > to save m
On Wed, Jul 22, 2020 at 05:26:09PM +0800, Yue Hu wrote:
> From: Yue Hu
>
> Currently, sysrq_key_table[] has 10 slots for same interface to change
> console loglevel. No specific purpose to do that. Let's use only one slot
> to save memory space. Also, update the key2index calculation. And remove
From: Yue Hu
Currently, sysrq_key_table[] has 10 slots for same interface to change
console loglevel. No specific purpose to do that. Let's use only one slot
to save memory space. Also, update the key2index calculation. And remove
needless code in help message print path to make the logic simpler
On Mon 2019-01-14 14:36:42, Sergey Senozhatsky wrote:
> On (01/11/19 16:32), Petr Mladek wrote:
> > The same problem is with the sysrq header line. It uses the trick
> > with console_loglevel by intention. We want to show it but
> > it is not really an error message
>
> May be.
>
> I usually see
On (01/11/19 16:32), Petr Mladek wrote:
> The same problem is with the sysrq header line. It uses the trick
> with console_loglevel by intention. We want to show it but
> it is not really an error message
May be.
I usually see it as an "error".
My case:
systemd sets sysrq on every boot to /
On Fri, 11 Jan 2019 22:07:29 +0900
Sergey Senozhatsky wrote:
> On (01/11/19 13:45), Petr Mladek wrote:
> > The sysrq header line is printed with an increased loglevel
> > to provide users some positive feedback.
> >
> > The original loglevel is not restored when the sysrq operation
> > is disabl
On Fri 2019-01-11 22:07:29, Sergey Senozhatsky wrote:
> On (01/11/19 13:45), Petr Mladek wrote:
> > The sysrq header line is printed with an increased loglevel
> > to provide users some positive feedback.
> >
> > The original loglevel is not restored when the sysrq operation
> > is disabled. This
On (01/11/19 13:45), Petr Mladek wrote:
> The sysrq header line is printed with an increased loglevel
> to provide users some positive feedback.
>
> The original loglevel is not restored when the sysrq operation
> is disabled. This bug was introduced in 2.6.12 (pre-git-history)
> by the commit ("A
The sysrq header line is printed with an increased loglevel
to provide users some positive feedback.
The original loglevel is not restored when the sysrq operation
is disabled. This bug was introduced in 2.6.12 (pre-git-history)
by the commit ("Allow admin to enable only some of the Magic-Sysrq
fu
On Thu, Sep 20, 2018 at 4:31 AM Greg KH wrote:
>
> On Wed, Sep 19, 2018 at 10:59:51AM -0700, Nick Desaulniers wrote:
> > On Tue, Sep 18, 2018 at 5:32 PM Matthias Kaehlcke wrote:
> > >
> > > sysrq_handle_crash() currently forces a crash by dereferencing a
> > > NULL pointer, which is undefined beh
On Wed, Sep 19, 2018 at 10:59:51AM -0700, Nick Desaulniers wrote:
> On Tue, Sep 18, 2018 at 5:32 PM Matthias Kaehlcke wrote:
> >
> > sysrq_handle_crash() currently forces a crash by dereferencing a
> > NULL pointer, which is undefined behavior in C. Just call panic()
> > instead, which is simpler
On Wed, Sep 19, 2018 at 10:59:51AM -0700, Nick Desaulniers wrote:
> On Tue, Sep 18, 2018 at 5:32 PM Matthias Kaehlcke wrote:
> >
> > sysrq_handle_crash() currently forces a crash by dereferencing a
> > NULL pointer, which is undefined behavior in C. Just call panic()
> > instead, which is simpler
On Tue, Sep 18, 2018 at 5:32 PM Matthias Kaehlcke wrote:
>
> sysrq_handle_crash() currently forces a crash by dereferencing a
> NULL pointer, which is undefined behavior in C. Just call panic()
> instead, which is simpler and doesn't depend on compiler specific
> handling of the undefined behavior
sysrq_handle_crash() currently forces a crash by dereferencing a
NULL pointer, which is undefined behavior in C. Just call panic()
instead, which is simpler and doesn't depend on compiler specific
handling of the undefined behavior.
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Matthias Kaehlck
c_notifier_list,
> >&sysrq_on_panic_nb);
> > return 0;
> > }
> > late_initcall(sysrq_on_panic_init);
> >
> >
> > Maybe this code (with enable/disable switch added)
On 09/13/2017, 08:04 AM, Jiri Slaby wrote:
> On 09/11/2017, 01:22 PM, Jibin Xu wrote:
>> Hi,Jiri:
>>
>> I tested get_irq_regs() behave in the softirq context,
>> I called get_irq_regs() by a tasklet, It returns NULL.My understanding is
>> get_irq_regs() can return the right result
>> only in hard
On 09/11/2017, 01:22 PM, Jibin Xu wrote:
> Hi,Jiri:
>
> I tested get_irq_regs() behave in the softirq context,
> I called get_irq_regs() by a tasklet, It returns NULL.My understanding is
> get_irq_regs() can return the right result
> only in hardware IRQ,otherwise it returns ＮＵＬL.
> So I t
Hi,Jiri:
get_irq_regs() in the softirq context return NULL.
thanks,
Jibin Xu
On 2017年09月11日 13:24, Jiri Slaby wrote:
On 09/11/2017, 05:11 AM, Jibin Xu wrote:
...
--- a/drivers/tty/sysrq.c
+++ b/drivers/tty/sysrq.c
@@ -245,8 +245,10 @@ static void sysrq_handle_showallcpus(int key)
* a
On 09/11/2017, 05:11 AM, Jibin Xu wrote:
...
> --- a/drivers/tty/sysrq.c
> +++ b/drivers/tty/sysrq.c
> @@ -245,8 +245,10 @@ static void sysrq_handle_showallcpus(int key)
>* architecture has no support for it:
>*/
> if (!trigger_all_cpu_backtrace()) {
> - struct pt_
When kernel configuration SMP,PREEMPT and DEBUG_PREEMPT are enabled,
echo 1 >/proc/sys/kernel/sysrq
echo p >/proc/sysrq-trigger
kernel will print call trace as below:
sysrq: SysRq : Show Regs
BUG: using __this_cpu_read() in preemptible [] code: sh/435
caller is __this_cpu_preempt_check+0x1
On Fri, Jan 06, 2017 at 02:14:16AM +0900, Akinobu Mita wrote:
> The sysrq input handler should be attached to the input device which has
> a left alt key.
>
> On 32-bit kernels, some input devices which has a left alt key cannot
> attach sysrq handler. Because the keybit bitmap in struct input_de
The sysrq input handler should be attached to the input device which has
a left alt key.
On 32-bit kernels, some input devices which has a left alt key cannot
attach sysrq handler. Because the keybit bitmap in struct input_device_id
for sysrq is not correctly initialized. KEY_LEFTALT is 56 which
On systems with a large number of CPUs, running sysrq- can cause
watchdog timeouts. There are two slow sections of code in the sysrq-
path in timer_list.c.
1. print_active_timers() - This function is called by print_cpu() and
contains a slow goto loop. On a machine with hundreds of CPUs, this
On Wed 06-01-16 20:49:23, Tetsuo Handa wrote:
> Michal Hocko wrote:
> > On Tue 05-01-16 17:22:46, Michal Hocko wrote:
> > > On Wed 30-12-15 15:33:47, Tetsuo Handa wrote:
> > [...]
> > > > I wish for a kernel thread that does OOM-kill operation.
> > > > Maybe we can change the OOM reaper kernel thre
Michal Hocko wrote:
> On Tue 05-01-16 17:22:46, Michal Hocko wrote:
> > On Wed 30-12-15 15:33:47, Tetsuo Handa wrote:
> [...]
> > > I wish for a kernel thread that does OOM-kill operation.
> > > Maybe we can change the OOM reaper kernel thread to do it.
> > > What do you think?
> >
> > I do no thi
On Tue 05-01-16 17:22:46, Michal Hocko wrote:
> On Wed 30-12-15 15:33:47, Tetsuo Handa wrote:
[...]
> > I wish for a kernel thread that does OOM-kill operation.
> > Maybe we can change the OOM reaper kernel thread to do it.
> > What do you think?
>
> I do no think a separate kernel thread would he
On Tue 05-01-16 17:22:46, Michal Hocko wrote:
> I guess this is not only sysrq+f
> specific though. What about emergency reboot or manual crash invocation?
I am a fool. For some reason I thought that em. reboot and the crash
invocation rely on the WQ as well. They are not though. So scratch this
a
On Wed 30-12-15 15:33:47, Tetsuo Handa wrote:
> >From 7fcac2054b33dc3df6c5915a58f232b9b80bb1e6 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Wed, 30 Dec 2015 15:24:40 +0900
> Subject: [RFC][PATCH] sysrq: ensure manual invocation of the OOM killer under
> OOM livelock
>From 7fcac2054b33dc3df6c5915a58f232b9b80bb1e6 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Wed, 30 Dec 2015 15:24:40 +0900
Subject: [RFC][PATCH] sysrq: ensure manual invocation of the OOM killer under
OOM livelock
This patch is similar to what commit 373ccbe5927034b5 ("mm, vmsta
if check_mask is true and sysrq_on_maks returns false,
then, the code go through the 'else' statement.
if (!check_mask || sysrq_on_maks(..)) {
...
} else {
pr_cont("This sysrq operation is disabled.\n");
}
...
So, console_loglevel rem
On Sun, Sep 29, 2013 at 09:40:09PM -0400, Dave Jones wrote:
> On Mon, Sep 30, 2013 at 02:31:08AM +0100, Ben Hutchings wrote:
> > From: Bastian Blank
> >
> > Add a Kconfig variable to set the initial value of the Magic SysRq mask
> > (sysctl: kernel.sysrq).
> >
> > Signed-off-by: Ben Hutchi
On Mon, Sep 30, 2013 at 02:31:08AM +0100, Ben Hutchings wrote:
> From: Bastian Blank
>
> Add a Kconfig variable to set the initial value of the Magic SysRq mask
> (sysctl: kernel.sysrq).
>
> Signed-off-by: Ben Hutchings
> ---
> This has been in Debian for a while, but should probably be
From: Bastian Blank
Add a Kconfig variable to set the initial value of the Magic SysRq mask
(sysctl: kernel.sysrq).
Signed-off-by: Ben Hutchings
---
This has been in Debian for a while, but should probably be signed-off
by Bastian as well.
Debian sets this to 0x01b6, which excludes.
On 2013/3/7 5:39, Andrew Morton wrote:
> On Wed, 6 Mar 2013 12:07:34 +0800 "zhangwei(Jovi)"
> wrote:
>
>> See the help text output of /proc/sysrq-trigger:
>>
>>SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E)
>>memory-full-oom-kill(F) kill-all-tasks(I) ...
>>
>> Most comm
On Wed, 6 Mar 2013 12:07:34 +0800 "zhangwei(Jovi)"
wrote:
> See the help text output of /proc/sysrq-trigger:
>
>SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E)
>memory-full-oom-kill(F) kill-all-tasks(I) ...
>
> Most command is referenced by responding upper-case charac
On 03/05/13 20:07, zhangwei(Jovi) wrote:
> See the help text output of /proc/sysrq-trigger:
>
>SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E)
>memory-full-oom-kill(F) kill-all-tasks(I) ...
>
> Most command is referenced by responding upper-case character,
> this would hi
See the help text output of /proc/sysrq-trigger:
SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E)
memory-full-oom-kill(F) kill-all-tasks(I) ...
Most command is referenced by responding upper-case character,
this would hint user can trigger sysrq by upper-case character key,
On Thu, Aug 09, 2012 at 05:40:46PM +0200, Borislav Petkov wrote:
> From: Borislav Petkov
>
> One day I was playing with disabling the caches over CR0.CD and I wanted
> to check the current setting of the CD bit but there wasn't a way to do
> so from userspace because we #GP when accessing CR0.
>
From: Borislav Petkov
One day I was playing with disabling the caches over CR0.CD and I wanted
to check the current setting of the CD bit but there wasn't a way to do
so from userspace because we #GP when accessing CR0.
And then I thought, well, sysrq must have this. And it does:
$ echo p > /pr
Andrew Morton wrote:
> On Sun, 29 Jul 2007 13:29:26 +0300
> Avi Kivity <[EMAIL PROTECTED]> wrote:
>
>
>> If a cpu is spinning in the kernel but still responding to interrupts,
>> pressing sysrq-y will show you where it's spinning.
>>
>> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
>>
>> diff --
On Sun, 29 Jul 2007 13:29:26 +0300
Avi Kivity <[EMAIL PROTECTED]> wrote:
> If a cpu is spinning in the kernel but still responding to interrupts,
> pressing sysrq-y will show you where it's spinning.
>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
>
> diff --git a/drivers/char/sysrq.c b/driver
If a cpu is spinning in the kernel but still responding to interrupts,
pressing sysrq-y will show you where it's spinning.
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
index 39cc318..1dda709 100644
--- a/drivers/char/sysrq.c
+++ b/drivers/
On Sat, 6 Jan 2007 20:19:29 +0100 Torsten Kaiser wrote:
> On Saturday 06 January 2007 19:25, Randy Dunlap wrote:
> > On Fri, 5 Jan 2007 20:36:05 +0100 Olaf Hering wrote:
> > >
> > > Weird, who failed to run this command before adding new stuff?!
> > > find * -type f -print0 | xargs -0 env -i grep
On Saturday 06 January 2007 19:25, Randy Dunlap wrote:
> On Fri, 5 Jan 2007 20:36:05 +0100 Olaf Hering wrote:
> >
> > Weird, who failed to run this command before adding new stuff?!
> > find * -type f -print0 | xargs -0 env -i grep -nw register_sysrq_key
> >
> > sysrq x is for xmon, see arch/powerp
On Fri, 5 Jan 2007 20:36:05 +0100 Olaf Hering wrote:
> On Fri, Jan 05, Randy Dunlap wrote:
>
> > From: Randy Dunlap <[EMAIL PROTECTED]>
> >
> > SysRq showBlockedTasks is not done via B or T, it's done via X,
> > so put that in the Help message.
>
> Weird, who failed to run this command before a
On Fri, Jan 05, Randy Dunlap wrote:
> OK. There is also a collision on 'c':
>
> drivers/net/ibm_emac/ibm_emac_debug.c:195:
> return register_sysrq_key('c', &emac_sysrq_op)
>
> and sysrq_crashdump_op. I'd say ibm_emac needs to change too.
I have seen that too.
No idea if crashdump acutally
On Fri, 5 Jan 2007 20:36:05 +0100 Olaf Hering wrote:
> On Fri, Jan 05, Randy Dunlap wrote:
>
> > From: Randy Dunlap <[EMAIL PROTECTED]>
> >
> > SysRq showBlockedTasks is not done via B or T, it's done via X,
> > so put that in the Help message.
>
> Weird, who failed to run this command before a
On Fri, Jan 05, Randy Dunlap wrote:
> From: Randy Dunlap <[EMAIL PROTECTED]>
>
> SysRq showBlockedTasks is not done via B or T, it's done via X,
> so put that in the Help message.
Weird, who failed to run this command before adding new stuff?!
find * -type f -print0 | xargs -0 env -i grep -nw re
From: Randy Dunlap <[EMAIL PROTECTED]>
SysRq showBlockedTasks is not done via B or T, it's done via X,
so put that in the Help message.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/char/sysrq.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2620-rc3g4.orig/dri
Hi Andrew,
The following patch adds a sysrq-trigger mechanism for kexec
based crashdumps. Alt-Sysrq-c triggers a kexec based
crashdump. Please include this along with the crashdumps
patches in the -mm tree.
Thanks and Regards, Hari
Signed-off-by: Hariprasad Nellitheertha <[EMAIL PROTECTED]>
-
Hi!
>The following patch add more disk devices to the SysRq sync list (in both:
> -pre and -ac trees). Were the extra IDE devices intentionally omitted here?
No, ommiting them was probably bug.
> BTW, it would be probably nice to add some mon-x86 disk devices here...
True... Feel free to d
Hi,
The following patch add more disk devices to the SysRq sync list (in both:
-pre and -ac trees). Were the extra IDE devices intentionally omitted here?
BTW, it would be probably nice to add some mon-x86 disk devices here...
Andrzej
diff -uNr drivers/char/sysrq.c~ drivers/char/sysrq.c
---
Anyone interested in advanced debuging features:
I've reved the SysRQ Registration Patch, available at:
http://bama.ua.edu/~dunna001/sysrq-register/
The latest is 0.10, and applies to 2.2.18-pre9, 2.4.0-test10-pre6,
and 2.4.0-test10-pre7. I got tired of reving the patch accross
6 versions, so I
53 matches
Mail list logo
