On Jul 11, 2012, at 9:24 AM, Joakim Tjernlund wrote: > Joakim Tjernlund/Transmode wrote on 2012/06/04 11:06:41: >> >> Benjamin Herrenschmidt <b...@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@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
