[RFC] [PATCH] powerpc: Add MSR_DE to MSR_KERNEL

[Kumar Gala]

On Jul 11, 2012, at 9:24 AM, Joakim Tjernlund wrote:

> Joakim Tjernlund/Transmode wrote on 2012/06/04 11:06:41:
>> 
>> Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote on 2012/06/02 23:21:16:
>>> 
>>> On Sat, 2012-06-02 at 20:29 +0200, Joakim Tjernlund wrote:
>>>> 
>>>> hmm, where does this go w.r.t the patch? Got the feeling that the
>>>> best thing is to just turn MSR:DE on and be done with it?
>>> 
>>> Not unconditionally, we need to have a close look, that might be ok
>>> specifically for BookE 32-bit, it's certainly not ok for BookE 64-bit at
>>> this point.
>>> 
>>> For now, I'm ok with a debug CONFIG_* option.
>>> 
>>> Also do we know if MSR:DE has any performance impact on any CPU ? I know
>>> having DACs enabled has a major impact on some for example.
>> 
>> I just sent a new patch, named
>>  [PATCH] powerpc: Add MSR_DE to MSR_KERNEL
>> which will only add MSR_DE for booke under CONFIG_BDI_SWITCH
> 
> Now I tried running gdb in user space and then I get this(with the MSR_DE patch):
> root at P2020RDB ~ # ./gdb busybox
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "powerpc-softfloat-linux-gnu"...
> (no debugging symbols found)
> (gdb) run
> Starting program: /root/busybox
> (no debugging syOops: Exception in kernel mode, sig: 5 [#1]
> PREEMPT P1010 RDB
> Modules linked in:
> NIP: c00067dc LR: c02d1994 CTR: c004a97c
> REGS: dfef9f10 TRAP: 2002   Not tainted  (3.4.0+)
> MSR: 00021000 <CE,ME>  CR: 42002424  XER: 00000000
> TASK = df9a0b10[429] 'gdb' THREAD: dfb9a000
> GPR00: cc00cc00 dfb9bd70 df9a0b10 df9a0b10 df949ad0 c0396000 00000000 df949b0c
> GPR08: 00000000 40000000 00002786 c03b0000 2b833af6 10493068 10490000 105a62a0
> GPR16: 00000000 10490000 10490000 10490000 10490000 10490000 10490000 dfb2ce40
> GPR24: df949ad0 c02e0000 c02e0000 c03b20a4 00000004 dfb9a000 c0399ce0 df9a0b10
> NIP [c00067dc] __switch_to+0x74/0xc4
> LR [c02d1994] __schedule+0x1a0/0x3c0
> Call Trace:
> [dfb9bd70] [dfb9a000] 0xdfb9a000 (unreliable)
> [dfb9bd80] [c02d1994] __schedule+0x1a0/0x3c0
> [dfb9bdc0] [c02d1cb8] preempt_schedule+0x54/0x74
> [dfb9bdd0] [c0047fe0] try_to_wake_up+0x140/0x144
> [dfb9bdf0] [c002b0bc] ptrace_resume+0x70/0xbc
> [dfb9be00] [c002c044] ptrace_request+0x1e8/0x5f0
> [dfb9bec0] [c00032c4] arch_ptrace+0x30/0x8f8
> [dfb9bf10] [c002ba90] sys_ptrace+0xb4/0x3cc
> [dfb9bf40] [c000cf4c] ret_from_syscall+0x0/0x3c
> --- Exception: c01 at 0xfd607a4
>    LR = 0x101a4900
> Instruction dump:
> 41820040 80040234 7c184ba6 80040238 7c194ba6 8004023c 7c1c4ba6 80040240
> 7c1d4ba6 80040224 7c144ba6 80040228 <7c154ba6> 8004022c 7c164ba6 7c431378
> ---[ end trace 584ab4ed4087571b ]---
> 
> note: gdb[429] exited with preempt_count 268435458
> mbols found)
> (nBUG: scheduling while atomic: busybox/430/0x10000004
> o debugging symbModules linked in:ols found)
> 
> When I remove the patch it works. I got no idea were it goes wrong,
> any ideas?
> 
> Jocke

I was wondering if this was going to break user space debugging.  What's probably happening by having MSR_DE always set, you are getting debug exceptions while in the kernel because DBCR[ICMP] (instruction complete) is  set and the HW is taking an exception.  Previously MSR_DE would ONLY be set while in user mode and thus prevent "spurious" debug exceptions like this.

- k