[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