On 2017/07/31 02:22PM, Breno Leitao wrote:
> If tracing is enabled and you get into xmon, the tracing buffer
> continues to be updated, causing possible loss of data due to buffer
> overflow and unnecessary tracing information coming from xmon functions.
>
> This patch adds a new option that allows the tracing to be disabled and
> re-enabled from inside xmon.
How is this new option useful? In the next patch, you disable tracing by
default -- in what scenario do you expect to have to re-enable tracing
from within xmon?
>
> Signed-off-by: Breno Leitao <lei...@debian.org>
> ---
> arch/powerpc/xmon/xmon.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 0cbd910193fa..19276d2f2f25 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -89,6 +89,7 @@ static unsigned long nidump = 16;
> static unsigned long ncsum = 4096;
> static int termch;
> static char tmpstr[128];
> +static char tracing_enabled = 1;
>
> static long bus_error_jmp[JMP_BUF_LEN];
> static int catch_memory_errors;
> @@ -268,6 +269,7 @@ Commands:\n\
> Sr # read SPR #\n\
> Sw #v write v to SPR #\n\
> t print backtrace\n\
> + v trace enable/disable\n\
> x exit monitor and recover\n\
> X exit monitor and don't recover\n"
> #if defined(CONFIG_PPC64) && !defined(CONFIG_PPC_BOOK3E)
> @@ -983,6 +985,17 @@ cmds(struct pt_regs *excp)
> case 'x':
> case 'X':
> return cmd;
> + case 'v':
> + if (tracing_is_on()) {
> + printk("Disabling tracing\n");
> + tracing_enabled = 0;
> + tracing_off();
This only disables trace buffer updates - ftrace (and all its callbacks,
et al) remains active, which isn't desirable. Can you see if this works
for you:
https://patchwork.ozlabs.org/patch/769611/
- Naveen
