From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.windriver.com (mail.windriver.com [147.11.1.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.windriver.com", Issuer "Intel External Basic Issuing CA 3A" (not verified)) by ozlabs.org (Postfix) with ESMTPS id F2C6E2C0094 for ; Fri, 21 Dec 2012 13:02:43 +1100 (EST) Message-ID: <50D3C339.5000201@windriver.com> Date: Fri, 21 Dec 2012 10:02:33 +0800 From: "tiejun.chen" MIME-Version: 1.0 To: Kumar Gala Subject: Re: [v1][PATCH 3/6] book3e/kgdb: update thread's dbcr0 References: <1355994510-11934-1-git-send-email-tiejun.chen@windriver.com> <1355994510-11934-4-git-send-email-tiejun.chen@windriver.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, jason.wessel@windriver.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 12/21/2012 02:41 AM, Kumar Gala wrote: > > On Dec 20, 2012, at 3:08 AM, Tiejun Chen wrote: > >> gdb always need to generate a single step properly to invoke >> a kgdb state. But with lazy interrupt, book3e can't always >> trigger a debug exception with a single step since the current >> is blocked for handling those pending exception, then we miss >> that expected dbcr configuration at last to generate a debug >> exception. >> >> So here we also update thread's dbcr0 to make sure the current >> can go back with that missed dbcr0 configuration. >> >> Signed-off-by: Tiejun Chen >> --- >> arch/powerpc/kernel/kgdb.c | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c >> index c470a40..516b44b 100644 >> --- a/arch/powerpc/kernel/kgdb.c >> +++ b/arch/powerpc/kernel/kgdb.c >> @@ -426,8 +426,18 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code, >> /* set the trace bit if we're stepping */ >> if (remcom_in_buffer[0] == 's') { >> #ifdef CONFIG_PPC_ADV_DEBUG_REGS >> +#ifdef CONFIG_PPC_BOOK3E > > Should this really be CONFIG_PPC64 or CONFIG_PPC_BOOK3E_64? Yes, I think CONFIG_PPC_BOOK3E_64 is better currently. Because I didn't validate this on power arch since I have no a real machine :) > >> + /* With lazy interrut we have to update thread dbcr0 here >> + * to make sure we can set debug properly at last to invoke >> + * kgdb again to work well. >> + */ >> + current->thread.dbcr0 = >> + mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM; >> + mtspr(SPRN_DBCR0, current->thread.dbcr0); >> +#else >> mtspr(SPRN_DBCR0, >> mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM); >> +#endif > > Can we code this so we don't need the #else? I guess you're saying something like this: --- diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c index c470a40..b2df42a 100644 --- a/arch/powerpc/kernel/kgdb.c +++ b/arch/powerpc/kernel/kgdb.c @@ -409,7 +409,7 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code, struct pt_regs *linux_regs) { char *ptr = &remcom_in_buffer[1]; - unsigned long addr; + unsigned long addr, dbcr0; switch (remcom_in_buffer[0]) { /* @@ -426,8 +426,15 @@ int kgdb_arch_handle_exception(int vector, int signo, int err_code, /* set the trace bit if we're stepping */ if (remcom_in_buffer[0] == 's') { #ifdef CONFIG_PPC_ADV_DEBUG_REGS - mtspr(SPRN_DBCR0, - mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM); + dbcr0 = mfspr(SPRN_DBCR0) | DBCR0_IC | DBCR0_IDM; + mtspr(SPRN_DBCR0, dbcr0); +#ifdef CONFIG_PPC_BOOK3E_64 + /* With lazy interrut we have to update thread dbcr0 here + * to make sure we can set debug properly at last to invoke + * kgdb again to work well. + */ + current->thread.dbcr0 = dbcr0; +#endif linux_regs->msr |= MSR_DE; #else linux_regs->msr |= MSR_SE; -- 1.7.9.5 Tiejun