> There is probably no problem with your patch, but this patch cannot get > merged until there is something that is also queued to use this API. Are > there more patches in a series that are not posted to this list?
Yes, you're right. Have a look at the patch below. > Depending on what kind of code you have there for cleaning up the exception > this block might need to be moved further toward the end or you might need an > additional callback to institute a restart of the kernel execution. I am > assuming there was something special you had to do in terms of an IPI or > something to make the co-processor or other cpu sync and stop. > There might be other considerations you need in order to debug the state of > the other cpu or co-processor in the future via kdb or the info-threads in > gdb, depending on how the device is actually structured. I don't have to stop the modem cpu. There is modem watchdog API available so I have just used it for instructing modem watchdog to ignore any timing issues from Linux processes. Generally I am interested in debugging Linux state only and for that these two patches seem to be enough. Best Regards Michal Frynas >From 077f79c950f15ba0f4af08381b16d093a17c3354 Mon Sep 17 00:00:00 2001 From: Michal Frynas <[email protected]> Date: Wed, 7 Mar 2012 12:59:28 +0100 Subject: [PATCH] KGDB: modem watchdog immunization against kernel stopping On Qualcomm's MSM 8255 platform there are two processors running simultaneously and synchronizing constantly with each other. The ARM11 CPU executes Linux code while the ARM9 executes modem code. While debugging Linux code and stopping kernel on a breakpoint the synchronization breaks causing modem CPU to trigger hard reset. To avoid this modem_watchdog_control driver registers pre_exception handler where it instructs modem watchdog to ignore timing issues from Linux side. That handler is invoked every time the kernel enters breakpoint and then when leaving breakpoint post_exception handler is called restoring modem watchdog to its default behavior. Change-Id: I8ab73b1c8edcec1fe89b0d2f2dfbd03f0a617f57 --- arch/arm/mach-msm/Makefile | 2 + arch/arm/mach-msm/modem_watchdog_control.c | 35 +++++++++++++++++++ arch/arm/mach-msm/modem_watchdog_control.h | 50 ++++++++++++++++++++++++++++ 3 files changed, 87 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-msm/modem_watchdog_control.c create mode 100644 arch/arm/mach-msm/modem_watchdog_control.h diff --git a/arch/arm/mach-msm/Makefile b/arch/arm/mach-msm/Makefile index 7ce284d..9984467 100755 --- a/arch/arm/mach-msm/Makefile +++ b/arch/arm/mach-msm/Makefile @@ -208,3 +208,5 @@ endif obj-$(CONFIG_PMIC_TIME) += pmic_time.o obj-$(CONFIG_SEMC_MOGAMI_FELICA_SUPPORT) += semc_mogami_felica.o + +obj-$(CONFIG_KGDB) += modem_watchdog_control.o diff --git a/arch/arm/mach-msm/modem_watchdog_control.c b/arch/arm/mach-msm/modem_watchdog_control.c new file mode 100644 index 0000000..d64ae7e --- /dev/null +++ b/arch/arm/mach-msm/modem_watchdog_control.c @@ -0,0 +1,35 @@ +#include <proc_comm.h> +#include <modem_watchdog_control.h> + + +static int modem_watchdog_state; + +void modem_watchdog_disable(void) +{ + pr_info("kgdb: disabling modem watchdog on breakpoint\n"); + modem_watchdog_state = DOG_HALT_MONITORING; + msm_proc_comm(PCOM_SET_SW_WATCHDOG_STATE, &modem_watchdog_state, 0); +} + +void modem_watchdog_enable(void) +{ + pr_info("kgdb: reenabling modem watchdog\n"); + modem_watchdog_state = DOG_DEFAULT_STATE; + msm_proc_comm(PCOM_SET_SW_WATCHDOG_STATE, &modem_watchdog_state, 0); +} + +int get_modem_watchdog_state(void) +{ + return modem_watchdog_state; +} + +static int __init modem_watchdog_control_init(void) +{ + pr_info("kgdb: initializing modem watchdog control module\n"); + arch_kgdb_ops.pre_exception = modem_watchdog_disable; + arch_kgdb_ops.post_exception = modem_watchdog_enable; + + return 0; +} + +late_initcall(modem_watchdog_control_init); diff --git a/arch/arm/mach-msm/modem_watchdog_control.h b/arch/arm/mach-msm/modem_watchdog_control.h new file mode 100644 index 0000000..a42a350 --- /dev/null +++ b/arch/arm/mach-msm/modem_watchdog_control.h @@ -0,0 +1,50 @@ +#ifndef MODEM_WATCHDOG_CONTROL_H_ +#define MODEM_WATCHDOG_CONTROL_H_ + +#include <linux/kgdb.h> + +/*---------------------------------------------------------------------------- + Bits indicating watch dog state as set by remote processors + Copied from AMSS source codes: + amss/AMSS/products/7x30/core/debugtools/task/src/dog.c +----------------------------------------------------------------------------*/ + +/* + * Remote proc is requesting dog task to resume its default state + */ +#define DOG_DEFAULT_STATE 0x00000000 + +/* + * Remote proc is requesting dog monitoring to be halted/enabled + */ +#define DOG_HALT_MONITORING 0x00000001 + +/* Remote proc is requesting dog task to setup/clear conditions for + * entering modem halt state (timer based) + */ +#define DOG_HALT_MODEM 0x00000002 + +/* + * Needed for pre_breakpoint and post_breakpoing hooks. + */ +extern struct kgdb_arch arch_kgdb_ops; + +/* + * Sends DOG_HALT_MONITORING value to modem site causing the modem watchdog + * ignoring tasks timeouts while still kicking the hardware watchdog. + */ +extern void modem_watchdog_disable(void); + +/* + * Sends DOG_DEFAULT_STATE value to modem site causing the modem watchdog + * to resume its default tasks processing. + */ +extern void modem_watchdog_enable(void); + +/* + * Returns current status of modem watchdog. + */ +extern int get_modem_watchdog_state(void); + + +#endif /* MODEM_WATCHDOG_CONTROL_H_ */ -- 1.7.8.3 -----Original Message----- From: Jason Wessel [mailto:[email protected]] Sent: 20 marca 2012 13:12 To: Frynas Michal K Cc: [email protected] Subject: Re: [Kgdb-bugreport] KGDB: Extension to arch specific KGDB interface On 03/09/2012 05:10 AM, [email protected] wrote: > Hi, > > I've tried to lunch KGDB on Qualcomm's platform MSM-8255 and after few days > finally succeeded. > Because of the fact that platform is based on two ARM processors (radio/modem > based on ARM9 and Linux/apps based on ARM11) I needed to provide a few > modifications on the Linux side to secure modem MCU while suspending Linux on > the breakpoint. > In particular it was necessary to handle modem watchdog while hanging on > breakpoint to avoid resetting the platform. > What I wanted to achieve was suspending the modem watchdog when entering > breakpoint and resuming it when leaving breakpoint. For that I have extended > the architecture specific part of KGDB for two new hooks which are intended > to be set in arch/arm code. > > I think the arch code should have a chance to prepare for > breakpoint/exception and cleanup after it. > There is probably no problem with your patch, but this patch cannot get merged until there is something that is also queued to use this API. Are there more patches in a series that are not posted to this list? > >>From 9b7ccd2b1508c4a4b2e8af90fa3510de21e02499 Mon Sep 17 00:00:00 2001 > From: Michal Frynas <[email protected]> > Date: Fri, 9 Mar 2012 11:29:11 +0100 > Subject: [PATCH] KGDB: arch specific pre_exception and post_exception hooks > > Structure kgdb_arch extends for two new architecture specific hooks: > pre_exception being invoked before hitting a breakpoint and > post_exception called just after leaving the breakpoint. You also want to include a "Signed-off-by" line per the kernel.org guide lines. See section 5.4: http://www.linuxfoundation.org/content/how-participate-linux-community-0 > --- a/kernel/debug/debug_core.c > +++ b/kernel/debug/debug_core.c > @@ -568,6 +568,10 @@ return_normal: > if (dbg_io_ops->pre_exception) > dbg_io_ops->pre_exception(); > > + /* Call architecture specific pre_exception routine */ > + if (arch_kgdb_ops.pre_exception) > + arch_kgdb_ops.pre_exception(); > + > /* > * Get the passive CPU lock which will hold all the non-primary > * CPU in a spin state while the debugger is active > @@ -624,6 +628,10 @@ cpu_master_loop: > } > } > > + /* Call architecture specific post_exception routine */ > + if (arch_kgdb_ops.post_exception) > + arch_kgdb_ops.post_exception(); > + Depending on what kind of code you have there for cleaning up the exception this block might need to be moved further toward the end or you might need an additional callback to institute a restart of the kernel execution. I am assuming there was something special you had to do in terms of an IPI or something to make the co-processor or other cpu sync and stop. There might be other considerations you need in order to debug the state of the other cpu or co-processor in the future via kdb or the info-threads in gdb, depending on how the device is actually structured. Cheers, Jason. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Kgdb-bugreport mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
