[PATCH v2 0/3] Fix G12 PMU conflict

Marc Gonzalez marc.w.gonzalez at free.fr
Tue Mar 28 17:01:57 PDT 2023


On 27/03/2023 17:52, Marc Gonzalez wrote:

> [  222.699138] SError Interrupt on CPU2, code 0x00000000bf000000 -- SError
> [  222.699155] CPU: 2 PID: 159 Comm: perf Not tainted 6.2.0 #451
> [  222.699162] Hardware name: SEI Robotics SEI510 (DT)
> [  222.699165] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [  222.699170] pc : __arch_copy_from_user+0x1c8/0x230
> [  222.699184] lr : copy_page_from_iter_atomic+0x1d4/0x5d0
> [  222.699192] sp : ffff80000a313b50
> [  222.699195] x29: ffff80000a313b50 x28: 0000000000000000 x27: 0000000000001000
> [  222.699205] x26: ffff80000877da80 x25: ffff000000b27d00 x24: 0000000000001f90
> [  222.699213] x23: ffff000000000000 x22: 0000040000000000 x21: ffff80000a313d50
> [  222.699220] x20: ffff000005400000 x19: 0000000000001000 x18: 0000000000000000
> [  222.699227] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffa4b73f28
> [  222.699234] x14: 0000000000000000 x13: ffff80000875f3ac x12: ffff800008025714
> [  222.699241] x11: ffff800008085888 x10: ffff8000080855f4 x9 : ffff800008753188
> [  222.699247] x8 : 000000000000000f x7 : 0080000100000009 x6 : ffff0000054001a8
> [  222.699253] x5 : ffff000005401000 x4 : 0000000000000008 x3 : ffffffffffffff80
> [  222.699260] x2 : 0000000000000df8 x1 : 0000ffffa4b74100 x0 : ffff000005400000
> [  222.699270] Kernel panic - not syncing: Asynchronous SError Interrupt
> [  222.699274] CPU: 2 PID: 159 Comm: perf Not tainted 6.2.0 #451
> [  222.699279] Hardware name: SEI Robotics SEI510 (DT)
> [  222.699284] Call trace:
> [  222.699286]  dump_backtrace.part.0+0xe0/0xf0
> [  222.699298]  show_stack+0x18/0x30
> [  222.699303]  dump_stack_lvl+0x68/0x84
> [  222.699314]  dump_stack+0x18/0x34
> [  222.699319]  panic+0x184/0x344
> [  222.699327]  nmi_panic+0xac/0xb0
> [  222.699334]  arm64_serror_panic+0x6c/0x80
> [  222.699339]  do_serror+0x58/0x60
> [  222.699343]  el1h_64_error_handler+0x30/0x50
> [  222.699347]  el1h_64_error+0x64/0x68
> [  222.699351]  __arch_copy_from_user+0x1c8/0x230
> [  222.699357]  generic_perform_write+0xe8/0x1e0
> [  222.699366]  __generic_file_write_iter+0x11c/0x1b0
> [  222.699374]  generic_file_write_iter+0x78/0x110
> [  222.699380]  vfs_write+0x2b0/0x390
> [  222.699388]  ksys_write+0x68/0x100
> [  222.699394]  __arm64_sys_write+0x1c/0x30
> [  222.699400]  invoke_syscall+0x48/0x120
> [  222.699408]  el0_svc_common.constprop.0+0x44/0xf0
> [  222.699414]  do_el0_svc+0x38/0xc0
> [  222.699420]  el0_svc+0x2c/0x90
> [  222.699425]  el0t_64_sync_handler+0xb8/0xc0
> [  222.699430]  el0t_64_sync+0x190/0x194

In my (limited) experience, these types of panics are Linux
getting nuked from a more privileged context (trustzone).

And indeed, there was a typo in my device tree that disabled
one reserved-memory area. Doh!

After fixing the DT, I can run memtest=17 sucessfully, and
the perf run completes without a hitch.

Sorry for the noise.




More information about the linux-amlogic mailing list