* Panic in arch_hw_breakpoint_init() on Cortex-A9 (SPEAr1340) @ 2017-04-18 10:44 Lubomir Rintel 2017-04-18 13:03 ` Mark Rutland 0 siblings, 1 reply; 5+ messages in thread From: Lubomir Rintel @ 2017-04-18 10:44 UTC (permalink / raw) To: linux-arm-kernel Hi, I'm getting a crash that looks awfully lot like what ddc37832a1 [ARM: 8634/1: hw_breakpoint: blacklist Scorpion CPUs] aims to fix. My hardware doesn't use a Scorpion CPU though -- it uses a Cortex-A9 (cpuid=0x412fc091). [????0.157000] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM [????0.157000] Modules linked in: [????0.157000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-0.rc3.git0.2.spear2.fc26.armv7hl #1 [????0.157000] Hardware name: ST SPEAr1340 SoC with Flattened Device Tree [????0.157000] task: ef102b80 task.stack: ef0fa000 [????0.157000] PC is at arch_hw_breakpoint_init+0x130/0x2a0 [????0.157000] LR is at arch_hw_breakpoint_init+0x7c/0x2a0 [????0.157000] pc : [<c0e0538c>]????lr : [<c0e052d8>]????psr: 60000013 [????0.157000] sp : ef0fbee8??ip : 00000000??fp : 00000000 [????0.157000] r10: c0ea183c??r9 : c0f24814??r8 : 00000000 [????0.157000] r7 : 000000e4??r6 : c0ea1828??r5 : c112e488??r4 : c112e488 [????0.157000] r3 : 0000000f??r2 : 510002d0??r1 : 2e7a7000??r0 : 00000003 [????0.157000] Flags: nZCv??IRQs on??FIQs on??Mode SVC_32??ISA ARM??Segment none [????0.157000] Control: 10c5387d??Table: 0020404a??DAC: 00000051 [????0.157000] Process swapper/0 (pid: 1, stack limit = 0xef0fa220) [????0.157000] Stack: (0xef0fbee8 to 0xef0fc000) [????0.157000] bee0:???????????????????c0c7e6c6 ef182234 00000000 54410001 00000000 c0e0525c [????0.157000] bf00: ffffe000 c0ea1828 000000e4 c0301e08 c112d980 00000000 c0ea1800 c036ab70 [????0.157000] bf20: efffcd92 c036ab70 efffcd92 c036ab70 00000003 00000001 c0d9a670 000000e4 [????0.157000] bf40: 00000003 00000003 c0d9a710 c0d9a710 c10359ac 00000004 00000004 c112d980 [????0.157000] bf60: c0ea1828 000000e4 c112d980 c0ea183c 00000000 c0e00ec0 00000003 00000003 [????0.157000] bf80: 00000000 c0e005c0 00000000 c0a33600 00000000 00000000 00000000 00000000 [????0.157000] bfa0: 00000000 c0a33610 00000000 c0307ef8 00000000 00000000 00000000 00000000 [????0.157000] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [????0.157000] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff [????0.157000] [<c0e0538c>] (arch_hw_breakpoint_init) from [<c0301e08>] (do_one_initcall+0x12c/0x154) [????0.157000] [<c0301e08>] (do_one_initcall) from [<c0e00ec0>] (kernel_init_freeable+0x218/0x264) [????0.157000] [<c0e00ec0>] (kernel_init_freeable) from [<c0a33610>] (kernel_init+0x10/0x114) [????0.157000] [<c0a33610>] (kernel_init) from [<c0307ef8>] (ret_from_fork+0x14/0x3c) [????0.157000] Code: e1a00004 ebd52503 ebd522fa eaffffc5 (ee110e91) [????0.157000] ---[ end trace dc9bbf347b3b7b44 ]--- [????0.158000] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [????0.158000] [????0.158000] CPU1: stopping [????0.158000] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G??????D?????????4.11.0-0.rc3.git0.2.spear2.fc26.armv7hl #1 [????0.158000] Hardware name: ST SPEAr1340 SoC with Flattened Device Tree [????0.158000] [<c03117a0>] (unwind_backtrace) from [<c030c4d0>] (show_stack+0x18/0x1c) [????0.158000] [<c030c4d0>] (show_stack) from [<c063a044>] (dump_stack+0x80/0xa0) [????0.158000] [<c063a044>] (dump_stack) from [<c030f578>] (handle_IPI+0x154/0x29c) [????0.158000] [<c030f578>] (handle_IPI) from [<c03017ec>] (gic_handle_irq+0x7c/0x84) [????0.158000] [<c03017ec>] (gic_handle_irq) from [<c0a3978c>] (__irq_svc+0x6c/0x90) [????0.158000] Exception stack(0xef12df80 to 0xef12dfc8) [????0.158000] df80: 00000001 00000000 00000000 c031c800 00000000 00000000 ffffe000 c1004df4 [????0.158000] dfa0: c1004e58 412fc091 00000000 00000000 00000001 ef12dfd0 c0308988 c0308978 [????0.158000] dfc0: 60000013 ffffffff [????0.158000] [<c0a3978c>] (__irq_svc) from [<c0308978>] (arch_cpu_idle+0x24/0x40) [????0.158000] [<c0308978>] (arch_cpu_idle) from [<c0391a54>] (do_idle+0xfc/0x1d8) [????0.158000] [<c0391a54>] (do_idle) from [<c0391d84>] (cpu_startup_entry+0x20/0x24) [????0.158000] [<c0391d84>] (cpu_startup_entry) from [<00301a2c>] (0x301a2c) [????0.158000] Rebooting in 10 seconds.. Lubo ^ permalink raw reply [flat|nested] 5+ messages in thread
* Panic in arch_hw_breakpoint_init() on Cortex-A9 (SPEAr1340) 2017-04-18 10:44 Panic in arch_hw_breakpoint_init() on Cortex-A9 (SPEAr1340) Lubomir Rintel @ 2017-04-18 13:03 ` Mark Rutland 2017-04-18 17:11 ` Lubomir Rintel 0 siblings, 1 reply; 5+ messages in thread From: Mark Rutland @ 2017-04-18 13:03 UTC (permalink / raw) To: linux-arm-kernel On Tue, Apr 18, 2017 at 12:44:28PM +0200, Lubomir Rintel wrote: > Hi, Hi, > I'm getting a crash that looks awfully lot like what ddc37832a1 [ARM: > 8634/1: hw_breakpoint: blacklist Scorpion CPUs] aims to fix. Just to check, have you successfully booted a kernel on this board before? i.e. is this a new crash? > My hardware doesn't use a Scorpion CPU though -- it uses a Cortex-A9 > (cpuid=0x412fc091). > > [????0.157000] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM > [????0.157000] Modules linked in: > [????0.157000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-0.rc3.git0.2.spear2.fc26.armv7hl #1 > [????0.157000] Hardware name: ST SPEAr1340 SoC with Flattened Device Tree > [????0.157000] task: ef102b80 task.stack: ef0fa000 > [????0.157000] PC is at arch_hw_breakpoint_init+0x130/0x2a0 > [????0.157000] LR is at arch_hw_breakpoint_init+0x7c/0x2a0 > [????0.157000] pc : [<c0e0538c>]????lr : [<c0e052d8>]????psr: 60000013 It would be helpful to know which specific access that is. Can you figure that out with addr2line, e.g. $ addr2line -ife vmlinux c0e0538c Thanks, Mark ^ permalink raw reply [flat|nested] 5+ messages in thread
* Panic in arch_hw_breakpoint_init() on Cortex-A9 (SPEAr1340) 2017-04-18 13:03 ` Mark Rutland @ 2017-04-18 17:11 ` Lubomir Rintel 2017-04-19 9:31 ` Mark Rutland 0 siblings, 1 reply; 5+ messages in thread From: Lubomir Rintel @ 2017-04-18 17:11 UTC (permalink / raw) To: linux-arm-kernel On Tue, 2017-04-18 at 14:03 +0100, Mark Rutland wrote: > On Tue, Apr 18, 2017 at 12:44:28PM +0200, Lubomir Rintel wrote: > > Hi, > > Hi, > > > I'm getting a crash that looks awfully lot like what ddc37832a1 [ARM: > > 8634/1: hw_breakpoint: blacklist Scorpion CPUs] aims to fix. > > Just to check, have you successfully booted a kernel on this board > before? i.e. is this a new crash? I've now checked, and it doesn't seem like it ever worked when PERF_EVENTS (and in turn HAVE_HW_BREAKPOINT) is enabled. The crash look the same up to 4.7; the previous versions also crash as soon as I enable the options but for some reason I don't get an oops on the console even with earlyprintk enabled (the machine reboots with panic= argument, so there's just possibly just something wrong with the console). > > My hardware doesn't use a Scorpion CPU though -- it uses a Cortex-A9 > > (cpuid=0x412fc091). > > > > [????0.157000] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM > > [????0.157000] Modules linked in: > > [????0.157000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-0.rc3.git0.2.spear2.fc26.armv7hl #1 > > [????0.157000] Hardware name: ST SPEAr1340 SoC with Flattened Device Tree > > [????0.157000] task: ef102b80 task.stack: ef0fa000 > > [????0.157000] PC is at arch_hw_breakpoint_init+0x130/0x2a0 > > [????0.157000] LR is at arch_hw_breakpoint_init+0x7c/0x2a0 > > [????0.157000] pc : [<c0e0538c>]????lr : [<c0e052d8>]????psr: 60000013 > > It would be helpful to know which specific access that is. > > Can you figure that out with addr2line, e.g. > > ?$ addr2line -ife vmlinux c0e0538c Internal error: Oops - undefined instruction: 0 [#1] SMP ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc7 #21 Hardware name: ST SPEAr1340 SoC with Flattened Device Tree task: ef058000 task.stack: ef04c000 PC is at arch_hw_breakpoint_init+0x9c/0x2a4 LR is at arch_hw_breakpoint_init+0x84/0x2a4 pc : [<c0905504>]????lr : [<c09054ec>]????psr: 60000013 $ addr2line -ife vmlinux c0905504 core_has_os_save_restore /home/lkundrak/spear/linux/arch/arm/kernel/hw_breakpoint.c:920 arch_hw_breakpoint_init /home/lkundrak/spear/linux/arch/arm/kernel/hw_breakpoint.c:1082 > > Thanks, > Mark ^ permalink raw reply [flat|nested] 5+ messages in thread
* Panic in arch_hw_breakpoint_init() on Cortex-A9 (SPEAr1340) 2017-04-18 17:11 ` Lubomir Rintel @ 2017-04-19 9:31 ` Mark Rutland 2022-05-10 7:22 ` Arnd Bergmann 0 siblings, 1 reply; 5+ messages in thread From: Mark Rutland @ 2017-04-19 9:31 UTC (permalink / raw) To: linux-arm-kernel On Tue, Apr 18, 2017 at 07:11:21PM +0200, Lubomir Rintel wrote: > On Tue, 2017-04-18 at 14:03 +0100, Mark Rutland wrote: > > On Tue, Apr 18, 2017 at 12:44:28PM +0200, Lubomir Rintel wrote: > > > I'm getting a crash that looks awfully lot like what ddc37832a1 [ARM: > > > 8634/1: hw_breakpoint: blacklist Scorpion CPUs] aims to fix. > > > > Just to check, have you successfully booted a kernel on this board > > before? i.e. is this a new crash? > > I've now checked, and it doesn't seem like it ever worked when > PERF_EVENTS (and in turn HAVE_HW_BREAKPOINT) is enabled. The crash look > the same up to 4.7; the previous versions also crash as soon as I > enable the options but for some reason I don't get an oops on the > console even with earlyprintk enabled (the machine reboots with panic= > argument, so there's just possibly just something wrong with the > console). Ok. So this isn't a recent regression. > > > My hardware doesn't use a Scorpion CPU though -- it uses a Cortex-A9 > > > (cpuid=0x412fc091). > > > > > > [????0.157000] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM > > > [????0.157000] Modules linked in: > > > [????0.157000] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-0.rc3.git0.2.spear2.fc26.armv7hl #1 > > > [????0.157000] Hardware name: ST SPEAr1340 SoC with Flattened Device Tree > > > [????0.157000] task: ef102b80 task.stack: ef0fa000 > > > [????0.157000] PC is at arch_hw_breakpoint_init+0x130/0x2a0 > > > [????0.157000] LR is at arch_hw_breakpoint_init+0x7c/0x2a0 > > > [????0.157000] pc : [<c0e0538c>]????lr : [<c0e052d8>]????psr: 60000013 > > > > It would be helpful to know which specific access that is. > > > > Can you figure that out with addr2line, e.g. > > > > ?$ addr2line -ife vmlinux c0e0538c > > Internal error: Oops - undefined instruction: 0 [#1] SMP ARM > Modules linked in: > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc7 #21 > Hardware name: ST SPEAr1340 SoC with Flattened Device Tree > task: ef058000 task.stack: ef04c000 > PC is at arch_hw_breakpoint_init+0x9c/0x2a4 > LR is at arch_hw_breakpoint_init+0x84/0x2a4 > pc : [<c0905504>]????lr : [<c09054ec>]????psr: 60000013 > > $ addr2line -ife vmlinux c0905504 > core_has_os_save_restore > /home/lkundrak/spear/linux/arch/arm/kernel/hw_breakpoint.c:920 That's a read of DBGOSLSR, which shouldn't UNDEF. I suspect this is a result of Cortex-A9 erratum 764319, which causes DBGOSLSR to unexpectedly behave as UNDEF when the external DBGSWENABLE pin is wired to 0. The official workaround is to ensure that the DBGSWENABLE pin is wired to 1. It might be possible to handle the trap and bail out, but it's not clear to me if we can safely assume that other functionality is available. Thanks, Mark. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Panic in arch_hw_breakpoint_init() on Cortex-A9 (SPEAr1340) 2017-04-19 9:31 ` Mark Rutland @ 2022-05-10 7:22 ` Arnd Bergmann 0 siblings, 0 replies; 5+ messages in thread From: Arnd Bergmann @ 2022-05-10 7:22 UTC (permalink / raw) To: Mark Rutland; +Cc: Lubomir Rintel, Linux ARM, Hawkins, Nick On Wed, Apr 19, 2017 at 11:31 AM Mark Rutland <mark.rutland@arm.com> wrote: > On Tue, Apr 18, 2017 at 07:11:21PM +0200, Lubomir Rintel wrote: > > On Tue, 2017-04-18 at 14:03 +0100, Mark Rutland wrote: > > > On Tue, Apr 18, 2017 at 12:44:28PM +0200, Lubomir Rintel wrote: > > $ addr2line -ife vmlinux c0905504 > > core_has_os_save_restore > > /home/lkundrak/spear/linux/arch/arm/kernel/hw_breakpoint.c:920 > > That's a read of DBGOSLSR, which shouldn't UNDEF. > > I suspect this is a result of Cortex-A9 erratum 764319, which causes > DBGOSLSR to unexpectedly behave as UNDEF when the external DBGSWENABLE > pin is wired to 0. > > The official workaround is to ensure that the DBGSWENABLE pin is wired > to 1. > > It might be possible to handle the trap and bail out, but it's not clear > to me if we can safely assume that other functionality is available. I searched for 764319 as Nick posted a patch for an errata workaround recently. If this problem still exists on the SPEAr1340, maybe the same patch will fix it. See [1] for the initial proposal that worked for Nick. I think there is a better way to do it, but either way it should address other platforms as well. Arnd [1] https://lore.kernel.org/lkml/20220506192957.24889-1-nick.hawkins@hpe.com/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-05-10 7:50 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-04-18 10:44 Panic in arch_hw_breakpoint_init() on Cortex-A9 (SPEAr1340) Lubomir Rintel 2017-04-18 13:03 ` Mark Rutland 2017-04-18 17:11 ` Lubomir Rintel 2017-04-19 9:31 ` Mark Rutland 2022-05-10 7:22 ` Arnd Bergmann
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox