From: Pan Xinhui <hidden> Date: 2017-02-15 02:55:31
Once xmon is triggered by sysrq-x, it is enabled always afterwards even
if it is disabled during boot. This will cause a system reset interrut
fail to dump. So keep xmon in its original state after exit.
Signed-off-by: Pan Xinhui <redacted>
---
arch/powerpc/xmon/xmon.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
From: Guilherme G. Piccoli <hidden> Date: 2017-02-15 21:22:29
On 15/02/2017 05:49, Pan Xinhui wrote:
Once xmon is triggered by sysrq-x, it is enabled always afterwards even
if it is disabled during boot. This will cause a system reset interrut
fail to dump. So keep xmon in its original state after exit.
Signed-off-by: Pan Xinhui <redacted>
Patch is fine - minor typo: interrut => interrupt
Feel free to add my:
Tested-by: Guilherme G. Piccoli <redacted>
Thanks,
Guilherme
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2017-02-16 05:09:25
Pan Xinhui [off-list ref] writes:
quoted hunk
Once xmon is triggered by sysrq-x, it is enabled always afterwards even
if it is disabled during boot. This will cause a system reset interrut
fail to dump. So keep xmon in its original state after exit.
Signed-off-by: Pan Xinhui <redacted>
---
arch/powerpc/xmon/xmon.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
I don't think this is right.
xmon_off is only true if you boot with xmon=off on the command line.
So if you boot with CONFIG_XMON_DEFAULT=n, and nothing on the command
line, then enter xmon via sysrq, then exit, xmon will still be enabled.
cheers
From: Guilherme G. Piccoli <hidden> Date: 2017-02-16 10:57:59
On 16/02/2017 03:09, Michael Ellerman wrote:
Pan Xinhui [off-list ref] writes:
quoted
Once xmon is triggered by sysrq-x, it is enabled always afterwards even
if it is disabled during boot. This will cause a system reset interrut
fail to dump. So keep xmon in its original state after exit.
Signed-off-by: Pan Xinhui <redacted>
---
arch/powerpc/xmon/xmon.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
I don't think this is right.
xmon_off is only true if you boot with xmon=off on the command line.
So if you boot with CONFIG_XMON_DEFAULT=n, and nothing on the command
line, then enter xmon via sysrq, then exit, xmon will still be enabled.
Agreed, noticed it after some work in V2 of my patch. I'm addressing it
there, so maybe no harm in keeping this way here..
Thanks,
Guilherme
From: Pan Xinhui <hidden> Date: 2017-02-16 11:52:36
在 2017/2/16 18:57, Guilherme G. Piccoli 写道:
On 16/02/2017 03:09, Michael Ellerman wrote:
quoted
Pan Xinhui [off-list ref] writes:
quoted
Once xmon is triggered by sysrq-x, it is enabled always afterwards even
if it is disabled during boot. This will cause a system reset interrut
fail to dump. So keep xmon in its original state after exit.
Signed-off-by: Pan Xinhui <redacted>
---
arch/powerpc/xmon/xmon.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
I don't think this is right.
xmon_off is only true if you boot with xmon=off on the command line.
So if you boot with CONFIG_XMON_DEFAULT=n, and nothing on the command
line, then enter xmon via sysrq, then exit, xmon will still be enabled.
Agreed, noticed it after some work in V2 of my patch. I'm addressing it
there, so maybe no harm in keeping this way here..
Hi, mpe
I cooked a new patch. And as Paul mentioned in slack, we need keep xmon on too if xmon=early is set in cmdline.
hi, Guilherme
feel free to include it in your new patchset. :)
thanks
xinhui
--------patch-----
powerpc/xmon: Fix an unexpected xmon onoff state change
Once xmon is triggered by sysrq-x, it is enabled always afterwards even
if it is disabled during boot. This will cause a system reset interrupt
fail to dump. So keep xmon in its original state after exit.
We have several ways to set xmon on or off.
1) by a build config CONFIG_XMON_DEFAULT.
2) by a boot cmdline with xmon or xmon=early or xmon=on to enable xmon
and xmon=off to disable xmon. This value will override that in step 1.
3) by a debugfs interface. We need someone implement it in the future.
And this value can override those in step 1 and 2.
Signed-off-by: Pan Xinhui <redacted>
---
arch/powerpc/xmon/xmon.c | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
@@ -3266,16 +3269,16 @@ static int __init setup_xmon_sysrq(void)__initcall(setup_xmon_sysrq);#endif /* CONFIG_MAGIC_SYSRQ */-staticint__initdataxmon_early,xmon_off;+staticint__initdataxmon_early;staticint__initearly_parse_xmon(char*p){if(!p||strncmp(p,"early",5)==0){/* just "xmon" is equivalent to "xmon=early" */-xmon_init(1);xmon_early=1;+xmon_off=0;}elseif(strncmp(p,"on",2)==0)-xmon_init(1);+xmon_off=0;elseif(strncmp(p,"off",3)==0)xmon_off=1;elseif(strncmp(p,"nobt",4)==0)
@@ -76,6 +76,7 @@ static int xmon_gate;#endif /* CONFIG_SMP */staticunsignedlongin_xmon__read_mostly=0;+staticintxmon_off=!IS_ENABLED(CONFIG_XMON_DEFAULT);
I think the logic would probably clearer if we invert this to become
xmon_on.
quoted hunk
@@ -3266,16 +3269,16 @@ static int __init setup_xmon_sysrq(void) __initcall(setup_xmon_sysrq); #endif /* CONFIG_MAGIC_SYSRQ */-static int __initdata xmon_early, xmon_off;+static int __initdata xmon_early; static int __init early_parse_xmon(char *p) { if (!p || strncmp(p, "early", 5) == 0) { /* just "xmon" is equivalent to "xmon=early" */- xmon_init(1); xmon_early = 1;+ xmon_off = 0; } else if (strncmp(p, "on", 2) == 0)- xmon_init(1);+ xmon_off = 0;
You've just changed the timing of when xmon gets enabled for the above
two cases, from here which is called very early, to xmon_setup() which
is called much later in boot.
That effectively disables xmon for most of the boot, which we do not
want to do.
cheers
@@ -76,6 +76,7 @@ static int xmon_gate;#endif /* CONFIG_SMP */staticunsignedlongin_xmon__read_mostly=0;+staticintxmon_off=!IS_ENABLED(CONFIG_XMON_DEFAULT);
I think the logic would probably clearer if we invert this to become
xmon_on.
yep, make sense.
quoted
@@ -3266,16 +3269,16 @@ static int __init setup_xmon_sysrq(void) __initcall(setup_xmon_sysrq); #endif /* CONFIG_MAGIC_SYSRQ */-static int __initdata xmon_early, xmon_off;+static int __initdata xmon_early; static int __init early_parse_xmon(char *p) { if (!p || strncmp(p, "early", 5) == 0) { /* just "xmon" is equivalent to "xmon=early" */- xmon_init(1); xmon_early = 1;+ xmon_off = 0; } else if (strncmp(p, "on", 2) == 0)- xmon_init(1);+ xmon_off = 0;
You've just changed the timing of when xmon gets enabled for the above
two cases, from here which is called very early, to xmon_setup() which
is called much later in boot.
That effectively disables xmon for most of the boot, which we do not
want to do.
Although it is not often that kernel got stucked during boot. Yes, the behavior changed anyway. Will fix that in v3.
@@ -76,6 +76,7 @@ static int xmon_gate;#endif /* CONFIG_SMP */staticunsignedlongin_xmon__read_mostly=0;+staticintxmon_off=!IS_ENABLED(CONFIG_XMON_DEFAULT);
I think the logic would probably clearer if we invert this to become
xmon_on.
yep, make sense.
quoted
quoted
@@ -3266,16 +3269,16 @@ static int __init setup_xmon_sysrq(void) __initcall(setup_xmon_sysrq); #endif /* CONFIG_MAGIC_SYSRQ */-static int __initdata xmon_early, xmon_off;+static int __initdata xmon_early; static int __init early_parse_xmon(char *p) { if (!p || strncmp(p, "early", 5) == 0) { /* just "xmon" is equivalent to "xmon=early" */- xmon_init(1); xmon_early = 1;+ xmon_off = 0; } else if (strncmp(p, "on", 2) == 0)- xmon_init(1);+ xmon_off = 0;
You've just changed the timing of when xmon gets enabled for the above
two cases, from here which is called very early, to xmon_setup() which
is called much later in boot.
That effectively disables xmon for most of the boot, which we do not
want to do.
Although it is not often that kernel got stucked during boot. Yes, the behavior changed anyway. Will fix that in v3.
Pan/Michael, I'm working my patches on top of Pan's. So, I sent his V2
on my series, as patch #1.
Guess the workflow is better/easier if we can work the patches on the
series exclusively, since each time Pan's patch is changed, I need to
refactor my patches.
Pan, if possible send your V3 to me, I'll refactor my series on top of
it and send again on the list. Or if you or Michael have better
suggestions of workflow, let me know.
Thanks,
Guilherme
@@ -76,6 +76,7 @@ static int xmon_gate;#endif /* CONFIG_SMP */staticunsignedlongin_xmon__read_mostly=3D0;+staticintxmon_off=3D!IS_ENABLED(CONFIG_XMON_DEFAULT);
I think the logic would probably clearer if we invert this to become
xmon_on.
yep, make sense.
quoted
quoted
@@ -3266,16 +3269,16 @@ static int __init setup_xmon_sysrq(void) __initcall(setup_xmon_sysrq); #endif /* CONFIG_MAGIC_SYSRQ */-static int __initdata xmon_early, xmon_off;+static int __initdata xmon_early; static int __init early_parse_xmon(char *p) { if (!p || strncmp(p, "early", 5) =3D=3D 0) { /* just "xmon" is equivalent to "xmon=3Dearly" */- xmon_init(1); xmon_early =3D 1;+ xmon_off =3D 0; } else if (strncmp(p, "on", 2) =3D=3D 0)- xmon_init(1);+ xmon_off =3D 0;
You've just changed the timing of when xmon gets enabled for the above
two cases, from here which is called very early, to xmon_setup() which
is called much later in boot.
That effectively disables xmon for most of the boot, which we do not
want to do.
Although it is not often that kernel got stucked during boot.