arm64: el1_error when copy rawdata to a partition

arm64: el1_error when copy rawdata to a partition

[Chris Ruehl]

Hi,

just hit a panic on my rk3399-orangepi while running

xz -d -c image.xz | dd of=/dev/mmcblk2p2 bs=1M

This can reproduce.

Any hints?
Regards
Chris

[  198.344203] 000: Kernel panic - not syncing: Asynchronous SError Interruptd+ 
 

[  198.351886] 000: CPU: 0 PID: 408 Comm: xz Not tainted 5.4.40-rt24 #35 
 

[  198.359080] 000: Hardware name: Orange Pi RK3399 Board (DT) 
 

[  198.365303] 000: Call trace: 
 

[  198.368504] 000:  dump_backtrace+0x0/0x140 
 

[  198.373078] 000:  show_stack+0x14/0x20 
 

[  198.377261] 000:  dump_stack+0xbc/0x100 
 

[  198.381542] 000:  panic+0x160/0x324 
 

[  198.385435] 000:  nmi_panic+0x60/0x90 
 

[  198.389521] 000:  arm64_serror_panic+0x74/0x80 
 

[  198.394481] 000:  do_serror+0x7c/0x130 
 

[  198.398664] 000:  el1_error+0x84/0xf8 
 

[  198.402751] 000:  __arch_copy_from_user+0x1f4/0x240 
 

[  198.408195] 000:  copy_page_from_iter+0xdc/0x2b0 
 

[  198.413351] 000:  pipe_write+0x204/0x448 
 

[  198.417731] 000:  new_sync_write+0x100/0x180 
 

[  198.422498] 000:  __vfs_write+0x2c/0x40 
 

[  198.426770] 000:  vfs_write+0xb0/0x1d0 
 

[  198.430954] 000:  ksys_write+0x64/0xe8 
 

[  198.435137] 000:  __arm64_sys_write+0x18/0x20 
 

[  198.440000] 000:  el0_svc_common.constprop.1+0x7c/0xe8 
 

[  198.445739] 000:  el0_svc_handler+0x20/0x80 
 

[  198.450408] 000:  el0_svc+0x8/0xc 
 

[  198.454107] 000: SMP: stopping secondary CPUs 
 

[  198.459064] 000: Kernel Offset: disabled 
 

[  198.463439] 000: CPU features: 0x0002,2000600c 
 

[  198.468399] 000: Memory Limit: none 
 

[  198.472293] 000: ---[ end Kernel panic - not syncing: Asynchronous SError 
Interrupt ]--- 

[  198.481330] 000: SError Interrupt on CPU0, code 0xbf000000 -- SError 
 

[  198.488426] 000: CPU: 0 PID: 408 Comm: xz Not tainted 5.4.40-rt24 #35 
 

[  198.495620] 000: Hardware name: Orange Pi RK3399 Board (DT) 
 

[  198.501841] 000: pstate: 60000085 (nZCv daIf -PAN -UAO) 
 

[  198.507674] 000: pc : el1_irq+0x78/0x180
[  198.512050] 000: lr : panic+0x2c0/0x324
[  198.516322] 000: sp : ffff80001129b8a0
[  198.520503] 000: x29: ffff80001129b9d0
[  198.524782] 000: x28: ffff0000750a9c00
[  198.529060] 000:
[  198.531201] 000: x27: 0000000000000001
[  198.535480] 000: x26: 0000000000000001
[  198.539757] 000:
[  198.541899] 000: x25: 0000000000000000
[  198.546178] 000: x24: ffff80001129bd60
[  198.550456] 000:
[  198.552597] 000: x23: 0000000060000145
[  198.556876] 000: x22: ffff8000100b5428
[  198.561154] 000:
[  198.563296] 000: x21: ffff80001129b9e0
[  198.567574] 000: x20: 0000ffffffffffff
[  198.571852] 000:
[  198.573994] 000: x19: ffff800010e40ba0
[  198.578272] 000: x18: 0000000000000010
[  198.582551] 000:
[  198.584692] 000: x17: 0000000000000000
[  198.588971] 000: x16: 0000000000000000
[  198.593249] 000:
[  198.595390] 000: x15: ffffffffffffffff
[  198.599669] 000: x14: 2d2d5d2074707572
[  198.603947] 000:
[  198.606089] 000: x13: 7265746e4920726f
[  198.610367] 000: x12: 727245532073756f
[  198.614646] 000:
[  198.616787] 000: x11: ffff800010dbf3f8
[  198.621065] 000: x10: 0000000000000001
[  198.625343] 000:
[  198.627484] 000: x9 : 00000000000734d0
[  198.631763] 000: x8 : ffff800010e48208
[  198.636041] 000:
[  198.638182] 000: x7 : ffff800010e45148
[  198.642461] 000: x6 : 00000000000734d0
[  198.646739] 000:
[  198.648881] 000: x5 : 00000000000030c0
[  198.653159] 000: x4 : 0000000000000000
[  198.657437] 000:
[  198.659579] 000: x3 : 0000000000000001
[  198.663857] 000: x2 : 0000000000000001
[  198.668135] 000:
[  198.670276] 000: x1 : ffff800010da9000
[  198.674555] 000: x0 : 00000000000000e0
[  198.678833] 000:

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: arm64: el1_error when copy rawdata to a partition

[Chris Ruehl]

Related Crash different command

xzcat image.xz | ssh root@10.1.1.1 "dd of=/dev/mmcblk2p2 bs=1M"


root@armhf2:~# [  341.336822] 003: Kernel panic - not syncing: Asynchronous 
SError Interrupt 

[  341.344509] 003: CPU: 3 PID: 410 Comm: dd Not tainted 5.4.44-rt27 #36 
 

[  341.351706] 003: Hardware name: Orange Pi RK3399 Board (DT) 
 

[  341.357931] 003: Call trace: 
 

[  341.361144] 003:  dump_backtrace+0x0/0x140 
 

[  341.365721] 003:  show_stack+0x14/0x20 
 

[  341.369909] 003:  dump_stack+0xbc/0x100 
 

[  341.374196] 003:  panic+0x160/0x324 
 

[  341.378094] 003:  nmi_panic+0x60/0x90 
 

[  341.382184] 003:  arm64_serror_panic+0x74/0x80 
 

[  341.387150] 003:  do_serror+0x7c/0x130 
 

[  341.391338] 003:  el1_error+0x84/0xf8 
 

[  341.395428] 003:  new_slab+0x1b0/0x370 
 

[  341.395982] 002: SError Interrupt on CPU2, code 0xbf000000 -- SError 
 

[  341.399619] 003:  ___slab_alloc+0x514/0x650 
 

[  341.406731] 002: CPU: 2 PID: 403 Comm: sshd Not tainted 5.4.44-rt27 #36 
 

[  341.411401] 003:  __slab_alloc.isra.99+0x4c/0x98 
 

[  341.418789] 002: Hardware name: Orange Pi RK3399 Board (DT) 
 

[  341.423944] 003:  kmem_cache_alloc+0x228/0x230 
 

[  341.430165] 002: pstate: 40000005 (nZcv daif -PAN -UAO) 
 

[  341.435124] 003:  alloc_buffer_head+0x1c/0xa0 
 

[  341.440958] 002: pc : do_translation_fault+0x28/0x70 
 

[  341.445823] 003:  alloc_page_buffers+0xa4/0x1e0 
 

[  341.451370] 002: lr : do_mem_abort+0x3c/0x98 
 

[  341.456426] 003:  create_empty_buffers+0x20/0x1c8 
 

[  341.461183] 002: sp : ffff800011403e80 
 

[  341.466426] 003:  create_page_buffers+0x68/0x78 
 

[  341.470607] 002: x29: ffff800011403e80 
 

[  341.475664] 003:  __block_write_begin_int+0x9c/0x798 
 

[  341.479943] 002: x28: ffff000078ad0000 
 

[  341.485476] 003:  block_write_begin+0x4c/0xd8 
 

[  341.489755] 002: 
 

[  341.494609] 003:  blkdev_write_begin+0x28/0x30 
 

[  341.496750] 002: x27: 0000000000000000 
 

[  341.501711] 003:  generic_perform_write+0xec/0x1a0 
 

[  341.505989] 002: x26: 0000ffffb7569000 
 

[  341.511339] 003:  __generic_file_write_iter+0x12c/0x198 
 

[  341.515617] 002: 
 

[  341.521452] 003:  blkdev_write_iter+0xa4/0x140 
 

[  341.523593] 002: x25: 0000000092000047 
 

[  341.528553] 003:  new_sync_write+0x100/0x180 
 

[  341.532831] 002: x24: 0000000000000024 
 

[  341.537599] 003:  __vfs_write+0x2c/0x40 
 

[  341.541877] 002: 
 

[  341.546157] 003:  vfs_write+0xb0/0x1d0 
 

[  341.548298] 002: x23: 0000000080000000 
 

[  341.552482] 003:  ksys_write+0x64/0xe8 
 

[  341.556760] 002: x22: 0000ffffb7569000 
 

[  341.560943] 003:  __arm64_sys_write+0x18/0x20 
 

[  341.565221] 002: 
 

[  341.570084] 003:  el0_svc_common.constprop.1+0x7c/0xe8 
 

[  341.572225] 002: x21: ffff800011403ec0 
 

[  341.577964] 003:  el0_svc_handler+0x20/0x80 
 

[  341.582242] 002: x20: 0000000092000047 
 

[  341.586903] 003:  el0_svc+0x8/0xc 
 

[  341.591181] 002: 
 

[  341.594881] 003: SMP: stopping secondary CPUs 
 

[  341.597020] 002: x19: ffff8000108a90a8 
 

[  341.606159] 002: x18: 0000000000000000 
 

[  341.610437] 002: 
 

[  341.612579] 002: x17: 0000000000000000 
 

[  341.616857] 002: x16: 0000000000000000 
 

[  341.621135] 002: 
 

[  341.623277] 002: x15: 0000000000000000 
 

[  341.627555] 002: x14: 0000000000000000 
 

[  341.631833] 002: 
 

[  341.633975] 002: x13: 0000000000000000 
 

[  341.638253] 002: x12: 0000000000000000 
 

[  341.642531] 002: 
 

[  341.644673] 002: x11: 0000000000000000 
 

[  341.648951] 002: x10: 0000000000000000 
 

[  341.653229] 002: 
 

[  341.655371] 002: x9 : 0000000000000000 
 

[  341.659649] 002: x8 : 0000000000000000 
 

[  341.663927] 002: 
 

[  341.666068] 002: x7 : 0000000000000000 
 

[  341.670346] 002: x6 : 0000000000000000 
 

[  341.674625] 002: 
 

[  341.676766] 002: x5 : 0000000000000018 
 

[  341.681045] 002: x4 : 0000000000000030 
 

[  341.685322] 002: 
 

[  341.687464] 002: x3 : 0000000000000001 
 

[  341.691742] 002: x2 : ffff800011403ec0 
 

[  341.696020] 002: 
 

[  341.698162] 002: x1 : 0000000092000047 
 

[  341.702440] 002: x0 : 0000ffffb7569000 
 

[  341.706718] 002: 
 

[  341.708862] 003: Kernel Offset: disabled 
 

[  341.713238] 003: CPU features: 0x0002,2000600c 
 

[  341.718197] 003: Memory Limit: none 
 

[  341.722091] 003: ---[ end Kernel panic - not syncing: Asynchronous SError 
Interrupt ]--- 

[  341.731130] 003: SError Interrupt on CPU3, code 0xbf000000 -- SError 
 

[  341.738217] 003: CPU: 3 PID: 410 Comm: dd Not tainted 5.4.44-rt27 #36 
 

[  341.745411] 003: Hardware name: Orange Pi RK3399 Board (DT) 
 

[  341.751632] 003: pstate: 60000085 (nZCv daIf -PAN -UAO) 
 

[  341.757456] 003: pc : el1_irq+0x78/0x180
[  341.761833] 003: lr : panic+0x2c0/0x324
[  341.766113] 003: sp : ffff8000113a3460
[  341.770295] 003: x29: ffff8000113a3590
[  341.774573] 003: x28: ffff000078b18e00
[  341.778851] 003:
[  341.780993] 003: x27: fffffdffbff67a00
[  341.785272] 003: x26: ffff000078bca200
[  341.789549] 003:
[  341.791691] 003: x25: 0000000000000005
[  341.795970] 003: x24: ffff000009c00208
[  341.800248] 003:
[  341.802390] 003: x23: 0000000060000145
[  341.806668] 003: x22: ffff8000100b53e8
[  341.810946] 003:
[  341.813088] 003: x21: ffff8000113a35a0
[  341.817366] 003: x20: 0000ffffffffffff
[  341.821644] 003:
[  341.823786] 003: x19: ffff800010e40ba0
[  341.828064] 003: x18: 0000000000000010
[  341.832342] 003:
[  341.834484] 003: x17: 0000000000000000
[  341.838762] 003: x16: 0000000000000000
[  341.843040] 003:
[  341.845182] 003: x15: ffffffffffffffff
[  341.849460] 003: x14: 2d2d5d2074707572
[  341.853738] 003:
[  341.855879] 003: x13: 7265746e4920726f
[  341.860158] 003: x12: 727245532073756f
[  341.864435] 003:
[  341.866577] 003: x11: ffff800010dbf3f8
[  341.870855] 003: x10: 0000000000000001
[  341.875133] 003:
[  341.877275] 003: x9 : 00000000000838e0
[  341.881553] 003: x8 : ffff800010e48618
[  341.885831] 003:
[  341.887973] 003: x7 : ffff800010e45148
[  341.892251] 003: x6 : 00000000000838e0
[  341.896529] 003:
[  341.898671] 003: x5 : 00000000000034d0
[  341.902949] 003: x4 : 0000000000000000
[  341.907227] 003:
[  341.909368] 003: x3 : 0000000000000001
[  341.913647] 003: x2 : 0000000000000001
[  341.917925] 003:
[  341.920067] 003: x1 : ffff800010da9000
[  341.924345] 003: x0 : 00000000000000e0
[  341.928623] 003:


On 10/6/2020 11:49 am, Chris Ruehl wrote:
> Hi,
> 
> just hit a panic on my rk3399-orangepi while running
> 
> xz -d -c image.xz | dd of=/dev/mmcblk2p2 bs=1M
> 
> This can reproduce.
> 
> Any hints?
> Regards
> Chris
> 
> [  198.344203] 000: Kernel panic - not syncing: Asynchronous SError Interruptd+
> 
> [  198.351886] 000: CPU: 0 PID: 408 Comm: xz Not tainted 5.4.40-rt24 #35
> 
> [  198.359080] 000: Hardware name: Orange Pi RK3399 Board (DT)
> 
> [  198.365303] 000: Call trace:
> 
> [  198.368504] 000:  dump_backtrace+0x0/0x140
> 
> [  198.373078] 000:  show_stack+0x14/0x20
> 
> [  198.377261] 000:  dump_stack+0xbc/0x100
> 
> [  198.381542] 000:  panic+0x160/0x324
> 
> [  198.385435] 000:  nmi_panic+0x60/0x90
> 
> [  198.389521] 000:  arm64_serror_panic+0x74/0x80
> 
> [  198.394481] 000:  do_serror+0x7c/0x130
> 
> [  198.398664] 000:  el1_error+0x84/0xf8
> 
> [  198.402751] 000:  __arch_copy_from_user+0x1f4/0x240
> 
> [  198.408195] 000:  copy_page_from_iter+0xdc/0x2b0
> 
> [  198.413351] 000:  pipe_write+0x204/0x448
> 
> [  198.417731] 000:  new_sync_write+0x100/0x180
> 
> [  198.422498] 000:  __vfs_write+0x2c/0x40
> 
> [  198.426770] 000:  vfs_write+0xb0/0x1d0
> 
> [  198.430954] 000:  ksys_write+0x64/0xe8
> 
> [  198.435137] 000:  __arm64_sys_write+0x18/0x20
> 
> [  198.440000] 000:  el0_svc_common.constprop.1+0x7c/0xe8
> 
> [  198.445739] 000:  el0_svc_handler+0x20/0x80
> 
> [  198.450408] 000:  el0_svc+0x8/0xc
> 
> [  198.454107] 000: SMP: stopping secondary CPUs
> 
> [  198.459064] 000: Kernel Offset: disabled
> 
> [  198.463439] 000: CPU features: 0x0002,2000600c
> 
> [  198.468399] 000: Memory Limit: none
> 
> [  198.472293] 000: ---[ end Kernel panic - not syncing: Asynchronous SError 
> Interrupt ]---
> [  198.481330] 000: SError Interrupt on CPU0, code 0xbf000000 -- SError
> 
> [  198.488426] 000: CPU: 0 PID: 408 Comm: xz Not tainted 5.4.40-rt24 #35
> 
> [  198.495620] 000: Hardware name: Orange Pi RK3399 Board (DT)
> 
> [  198.501841] 000: pstate: 60000085 (nZCv daIf -PAN -UAO)
> 
> [  198.507674] 000: pc : el1_irq+0x78/0x180
> [  198.512050] 000: lr : panic+0x2c0/0x324
> [  198.516322] 000: sp : ffff80001129b8a0
> [  198.520503] 000: x29: ffff80001129b9d0
> [  198.524782] 000: x28: ffff0000750a9c00
> [  198.529060] 000:
> [  198.531201] 000: x27: 0000000000000001
> [  198.535480] 000: x26: 0000000000000001
> [  198.539757] 000:
> [  198.541899] 000: x25: 0000000000000000
> [  198.546178] 000: x24: ffff80001129bd60
> [  198.550456] 000:
> [  198.552597] 000: x23: 0000000060000145
> [  198.556876] 000: x22: ffff8000100b5428
> [  198.561154] 000:
> [  198.563296] 000: x21: ffff80001129b9e0
> [  198.567574] 000: x20: 0000ffffffffffff
> [  198.571852] 000:
> [  198.573994] 000: x19: ffff800010e40ba0
> [  198.578272] 000: x18: 0000000000000010
> [  198.582551] 000:
> [  198.584692] 000: x17: 0000000000000000
> [  198.588971] 000: x16: 0000000000000000
> [  198.593249] 000:
> [  198.595390] 000: x15: ffffffffffffffff
> [  198.599669] 000: x14: 2d2d5d2074707572
> [  198.603947] 000:
> [  198.606089] 000: x13: 7265746e4920726f
> [  198.610367] 000: x12: 727245532073756f
> [  198.614646] 000:
> [  198.616787] 000: x11: ffff800010dbf3f8
> [  198.621065] 000: x10: 0000000000000001
> [  198.625343] 000:
> [  198.627484] 000: x9 : 00000000000734d0
> [  198.631763] 000: x8 : ffff800010e48208
> [  198.636041] 000:
> [  198.638182] 000: x7 : ffff800010e45148
> [  198.642461] 000: x6 : 00000000000734d0
> [  198.646739] 000:
> [  198.648881] 000: x5 : 00000000000030c0
> [  198.653159] 000: x4 : 0000000000000000
> [  198.657437] 000:
> [  198.659579] 000: x3 : 0000000000000001
> [  198.663857] 000: x2 : 0000000000000001
> [  198.668135] 000:
> [  198.670276] 000: x1 : ffff800010da9000
> [  198.674555] 000: x0 : 00000000000000e0
> [  198.678833] 000:
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
GTSYS Limited RFID Technology
9/F, Unit E, R07, Kwai Shing Industrial Building Phase 2,
42-46 Tai Lin Pai Road, Kwai Chung, N.T., Hong Kong
Tel (852) 9079 9521

Disclaimer: https://www.gtsys.com.hk/email/classified.html

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: arm64: el1_error when copy rawdata to a partition

[Robin Murphy]

Hi Chris,

On 2020-06-10 04:49, Chris Ruehl wrote:
> Hi,
> 
> just hit a panic on my rk3399-orangepi while running
> 
> xz -d -c image.xz | dd of=/dev/mmcblk2p2 bs=1M
> 
> This can reproduce.

What's your firmware setup? There's a known snag when mixing mainline 
U-Boot with Rockchip's Trusted Firmware binaries - the "trust.img" blobs 
tend to include an OP-TEE payload that carves out some DRAM for the 
Secure world, and the BSP U-Boot has some hard-coded handling for that 
whereas mainline doesn't. As a result, in that configuration Linux ends 
up unaware that some of the memory it's been told about isn't actually 
accessible and will trigger an external abort if touched (which due to 
the nature of the page allocator typically only seems to happen under 
memory pressure, like a large copy operation that churns a lot of data 
through the page cache).

Robin.

> Any hints?
> Regards
> Chris
> 
> [  198.344203] 000: Kernel panic - not syncing: Asynchronous SError 
> Interruptd+
> 
> [  198.351886] 000: CPU: 0 PID: 408 Comm: xz Not tainted 5.4.40-rt24 #35
> 
> [  198.359080] 000: Hardware name: Orange Pi RK3399 Board (DT)
> 
> [  198.365303] 000: Call trace:
> 
> [  198.368504] 000:  dump_backtrace+0x0/0x140
> 
> [  198.373078] 000:  show_stack+0x14/0x20
> 
> [  198.377261] 000:  dump_stack+0xbc/0x100
> 
> [  198.381542] 000:  panic+0x160/0x324
> 
> [  198.385435] 000:  nmi_panic+0x60/0x90
> 
> [  198.389521] 000:  arm64_serror_panic+0x74/0x80
> 
> [  198.394481] 000:  do_serror+0x7c/0x130
> 
> [  198.398664] 000:  el1_error+0x84/0xf8
> 
> [  198.402751] 000:  __arch_copy_from_user+0x1f4/0x240
> 
> [  198.408195] 000:  copy_page_from_iter+0xdc/0x2b0
> 
> [  198.413351] 000:  pipe_write+0x204/0x448
> 
> [  198.417731] 000:  new_sync_write+0x100/0x180
> 
> [  198.422498] 000:  __vfs_write+0x2c/0x40
> 
> [  198.426770] 000:  vfs_write+0xb0/0x1d0
> 
> [  198.430954] 000:  ksys_write+0x64/0xe8
> 
> [  198.435137] 000:  __arm64_sys_write+0x18/0x20
> 
> [  198.440000] 000:  el0_svc_common.constprop.1+0x7c/0xe8
> 
> [  198.445739] 000:  el0_svc_handler+0x20/0x80
> 
> [  198.450408] 000:  el0_svc+0x8/0xc
> 
> [  198.454107] 000: SMP: stopping secondary CPUs
> 
> [  198.459064] 000: Kernel Offset: disabled
> 
> [  198.463439] 000: CPU features: 0x0002,2000600c
> 
> [  198.468399] 000: Memory Limit: none
> 
> [  198.472293] 000: ---[ end Kernel panic - not syncing: Asynchronous 
> SError Interrupt ]---
> [  198.481330] 000: SError Interrupt on CPU0, code 0xbf000000 -- SError
> 
> [  198.488426] 000: CPU: 0 PID: 408 Comm: xz Not tainted 5.4.40-rt24 #35
> 
> [  198.495620] 000: Hardware name: Orange Pi RK3399 Board (DT)
> 
> [  198.501841] 000: pstate: 60000085 (nZCv daIf -PAN -UAO)
> 
> [  198.507674] 000: pc : el1_irq+0x78/0x180
> [  198.512050] 000: lr : panic+0x2c0/0x324
> [  198.516322] 000: sp : ffff80001129b8a0
> [  198.520503] 000: x29: ffff80001129b9d0
> [  198.524782] 000: x28: ffff0000750a9c00
> [  198.529060] 000:
> [  198.531201] 000: x27: 0000000000000001
> [  198.535480] 000: x26: 0000000000000001
> [  198.539757] 000:
> [  198.541899] 000: x25: 0000000000000000
> [  198.546178] 000: x24: ffff80001129bd60
> [  198.550456] 000:
> [  198.552597] 000: x23: 0000000060000145
> [  198.556876] 000: x22: ffff8000100b5428
> [  198.561154] 000:
> [  198.563296] 000: x21: ffff80001129b9e0
> [  198.567574] 000: x20: 0000ffffffffffff
> [  198.571852] 000:
> [  198.573994] 000: x19: ffff800010e40ba0
> [  198.578272] 000: x18: 0000000000000010
> [  198.582551] 000:
> [  198.584692] 000: x17: 0000000000000000
> [  198.588971] 000: x16: 0000000000000000
> [  198.593249] 000:
> [  198.595390] 000: x15: ffffffffffffffff
> [  198.599669] 000: x14: 2d2d5d2074707572
> [  198.603947] 000:
> [  198.606089] 000: x13: 7265746e4920726f
> [  198.610367] 000: x12: 727245532073756f
> [  198.614646] 000:
> [  198.616787] 000: x11: ffff800010dbf3f8
> [  198.621065] 000: x10: 0000000000000001
> [  198.625343] 000:
> [  198.627484] 000: x9 : 00000000000734d0
> [  198.631763] 000: x8 : ffff800010e48208
> [  198.636041] 000:
> [  198.638182] 000: x7 : ffff800010e45148
> [  198.642461] 000: x6 : 00000000000734d0
> [  198.646739] 000:
> [  198.648881] 000: x5 : 00000000000030c0
> [  198.653159] 000: x4 : 0000000000000000
> [  198.657437] 000:
> [  198.659579] 000: x3 : 0000000000000001
> [  198.663857] 000: x2 : 0000000000000001
> [  198.668135] 000:
> [  198.670276] 000: x1 : ffff800010da9000
> [  198.674555] 000: x0 : 00000000000000e0
> [  198.678833] 000:
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: arm64: el1_error when copy rawdata to a partition

[Chris Ruehl]

Hi Robin,

On 10/6/2020 7:58 pm, Robin Murphy wrote:
> Hi Chris,
>
> On 2020-06-10 04:49, Chris Ruehl wrote:
>> Hi,
>>
>> just hit a panic on my rk3399-orangepi while running
>>
>> xz -d -c image.xz | dd of=/dev/mmcblk2p2 bs=1M
>>
>> This can reproduce.
>
> What's your firmware setup? There's a known snag when mixing mainline U-Boot 
> with Rockchip's Trusted Firmware binaries - the "trust.img" blobs tend to 
> include an OP-TEE payload that carves out some DRAM for the Secure world, and 
> the BSP U-Boot has some hard-coded handling for that whereas mainline doesn't. 
> As a result, in that configuration Linux ends up unaware that some of the 
> memory it's been told about isn't actually accessible and will trigger an 
> external abort if touched (which due to the nature of the page allocator 
> typically only seems to happen under memory pressure, like a large copy 
> operation that churns a lot of data through the page cache).
>
> Robin.
Yes, I'm using the mini-loader from Rockchip and the trusted.img with the 
mainline uboot 2020.4
and what you tell me makes sense!

I tried to use the open-source only but failed end up with:
"Try booting from MMC1"
and then timeout on the SD & eMMC, I think the clock not come up
or isn't initialized in the SPL.

UBOOT config:
  List of device tree properties to drop for SPL:
... clock-names .. assigned-clocks assigned-clock-rates assigned-clock-parents

while I write this, I read about the "u-boot,dm-pre-reloc" in the help text - hmm
let me add this to the rk3399-orangepi.dts and give the pure open-source solution
one more try.

Thank you for your answer.
Chris



>
>> Any hints?
>> Regards
>> Chris
>>
>> [  198.344203] 000: Kernel panic - not syncing: Asynchronous SError Interruptd+
>>
>> [  198.351886] 000: CPU: 0 PID: 408 Comm: xz Not tainted 5.4.40-rt24 #35
>>
>> [  198.359080] 000: Hardware name: Orange Pi RK3399 Board (DT)
>>
>> [  198.365303] 000: Call trace:
>>
>> [  198.368504] 000:  dump_backtrace+0x0/0x140
>>
>> [  198.373078] 000:  show_stack+0x14/0x20
>>
>> [  198.377261] 000:  dump_stack+0xbc/0x100
>>
>> [  198.381542] 000:  panic+0x160/0x324
>>
>> [  198.385435] 000:  nmi_panic+0x60/0x90
>>
>> [  198.389521] 000:  arm64_serror_panic+0x74/0x80
>>
>> [  198.394481] 000:  do_serror+0x7c/0x130
>>
>> [  198.398664] 000:  el1_error+0x84/0xf8
>>
>> [  198.402751] 000:  __arch_copy_from_user+0x1f4/0x240
>>
>> [  198.408195] 000:  copy_page_from_iter+0xdc/0x2b0
>>
>> [  198.413351] 000:  pipe_write+0x204/0x448
>>
>> [  198.417731] 000:  new_sync_write+0x100/0x180
>>
>> [  198.422498] 000:  __vfs_write+0x2c/0x40
>>
>> [  198.426770] 000:  vfs_write+0xb0/0x1d0
>>
>> [  198.430954] 000:  ksys_write+0x64/0xe8
>>
>> [  198.435137] 000:  __arm64_sys_write+0x18/0x20
>>
>> [  198.440000] 000:  el0_svc_common.constprop.1+0x7c/0xe8
>>
>> [  198.445739] 000:  el0_svc_handler+0x20/0x80
>>
>> [  198.450408] 000:  el0_svc+0x8/0xc
>>
>> [  198.454107] 000: SMP: stopping secondary CPUs
>>
>> [  198.459064] 000: Kernel Offset: disabled
>>
>> [  198.463439] 000: CPU features: 0x0002,2000600c
>>
>> [  198.468399] 000: Memory Limit: none
>>
>> [  198.472293] 000: ---[ end Kernel panic - not syncing: Asynchronous SError 
>> Interrupt ]---
>> [  198.481330] 000: SError Interrupt on CPU0, code 0xbf000000 -- SError
>>
>> [  198.488426] 000: CPU: 0 PID: 408 Comm: xz Not tainted 5.4.40-rt24 #35
>>
>> [  198.495620] 000: Hardware name: Orange Pi RK3399 Board (DT)
>>
>> [  198.501841] 000: pstate: 60000085 (nZCv daIf -PAN -UAO)
>>
>> [  198.507674] 000: pc : el1_irq+0x78/0x180
>> [  198.512050] 000: lr : panic+0x2c0/0x324
>> [  198.516322] 000: sp : ffff80001129b8a0
>> [  198.520503] 000: x29: ffff80001129b9d0
>> [  198.524782] 000: x28: ffff0000750a9c00
>> [  198.529060] 000:
>> [  198.531201] 000: x27: 0000000000000001
>> [  198.535480] 000: x26: 0000000000000001
>> [  198.539757] 000:
>> [  198.541899] 000: x25: 0000000000000000
>> [  198.546178] 000: x24: ffff80001129bd60
>> [  198.550456] 000:
>> [  198.552597] 000: x23: 0000000060000145
>> [  198.556876] 000: x22: ffff8000100b5428
>> [  198.561154] 000:
>> [  198.563296] 000: x21: ffff80001129b9e0
>> [  198.567574] 000: x20: 0000ffffffffffff
>> [  198.571852] 000:
>> [  198.573994] 000: x19: ffff800010e40ba0
>> [  198.578272] 000: x18: 0000000000000010
>> [  198.582551] 000:
>> [  198.584692] 000: x17: 0000000000000000
>> [  198.588971] 000: x16: 0000000000000000
>> [  198.593249] 000:
>> [  198.595390] 000: x15: ffffffffffffffff
>> [  198.599669] 000: x14: 2d2d5d2074707572
>> [  198.603947] 000:
>> [  198.606089] 000: x13: 7265746e4920726f
>> [  198.610367] 000: x12: 727245532073756f
>> [  198.614646] 000:
>> [  198.616787] 000: x11: ffff800010dbf3f8
>> [  198.621065] 000: x10: 0000000000000001
>> [  198.625343] 000:
>> [  198.627484] 000: x9 : 00000000000734d0
>> [  198.631763] 000: x8 : ffff800010e48208
>> [  198.636041] 000:
>> [  198.638182] 000: x7 : ffff800010e45148
>> [  198.642461] 000: x6 : 00000000000734d0
>> [  198.646739] 000:
>> [  198.648881] 000: x5 : 00000000000030c0
>> [  198.653159] 000: x4 : 0000000000000000
>> [  198.657437] 000:
>> [  198.659579] 000: x3 : 0000000000000001
>> [  198.663857] 000: x2 : 0000000000000001
>> [  198.668135] 000:
>> [  198.670276] 000: x1 : ffff800010da9000
>> [  198.674555] 000: x0 : 00000000000000e0
>> [  198.678833] 000:
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
GTSYS Limited RFID Technology
9/F, Unit E, R07, Kwai Shing Industrial Building Phase 2,
42-46 Tai Lin Pai Road, Kwai Chung, N.T., Hong Kong
Tel (852) 9079 9521

Disclaimer: https://www.gtsys.com.hk/email/classified.html


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: arm64: el1_error when copy rawdata to a partition

[Robin Murphy]

On 2020-06-11 03:21, Chris Ruehl wrote:
> Hi Robin,
> 
> On 10/6/2020 7:58 pm, Robin Murphy wrote:
>> Hi Chris,
>>
>> On 2020-06-10 04:49, Chris Ruehl wrote:
>>> Hi,
>>>
>>> just hit a panic on my rk3399-orangepi while running
>>>
>>> xz -d -c image.xz | dd of=/dev/mmcblk2p2 bs=1M
>>>
>>> This can reproduce.
>>
>> What's your firmware setup? There's a known snag when mixing mainline 
>> U-Boot with Rockchip's Trusted Firmware binaries - the "trust.img" 
>> blobs tend to include an OP-TEE payload that carves out some DRAM for 
>> the Secure world, and the BSP U-Boot has some hard-coded handling for 
>> that whereas mainline doesn't. As a result, in that configuration 
>> Linux ends up unaware that some of the memory it's been told about 
>> isn't actually accessible and will trigger an external abort if 
>> touched (which due to the nature of the page allocator typically only 
>> seems to happen under memory pressure, like a large copy operation 
>> that churns a lot of data through the page cache).
>>
>> Robin.
> Yes, I'm using the mini-loader from Rockchip and the trusted.img with 
> the mainline uboot 2020.4
> and what you tell me makes sense!
> 
> I tried to use the open-source only but failed end up with:
> "Try booting from MMC1"
> and then timeout on the SD & eMMC, I think the clock not come up
> or isn't initialized in the SPL.
> 
> UBOOT config:
>   List of device tree properties to drop for SPL:
> ... clock-names .. assigned-clocks assigned-clock-rates 
> assigned-clock-parents
> 
> while I write this, I read about the "u-boot,dm-pre-reloc" in the help 
> text - hmm
> let me add this to the rk3399-orangepi.dts and give the pure open-source 
> solution
> one more try.

I do recall having to do some fiddling to get TPL/SPL to boot from eMMC 
reliably on my NanoPC-T4 - the only change I have committed locally is 
adding a "u-boot,spl-boot-order" property, but I can't now remember 
whether the image I'm currently using had any further temporary hacks on 
top of that.

An alternative workaround is just to hack the kernel DT to explicitly 
reserve the offending region - until I got mainline TPL/SPL and Trusted 
Firmware working, this is what I had:

	reserved-memory {
		#address-cells = <2>;
		#size-cells = <2>;
		ranges;

		external-abort@8400000 {
			reg = <0 0x8400000 0 0x1200000>;
			no-map;
		};
	};

Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: arm64: el1_error when copy rawdata to a partition

[Chris Ruehl]

On 11/6/2020 7:38 pm, Robin Murphy wrote:
> On 2020-06-11 03:21, Chris Ruehl wrote:
>> Hi Robin,
>>
>> On 10/6/2020 7:58 pm, Robin Murphy wrote:
>>> Hi Chris,
>>>
>>> On 2020-06-10 04:49, Chris Ruehl wrote:
>>>> Hi,
>>>>
>>>> just hit a panic on my rk3399-orangepi while running
>>>>
>>>> xz -d -c image.xz | dd of=/dev/mmcblk2p2 bs=1M
>>>>
>>>> This can reproduce.
>>>
>>> What's your firmware setup? There's a known snag when mixing mainline U-Boot 
>>> with Rockchip's Trusted Firmware binaries - the "trust.img" blobs tend to 
>>> include an OP-TEE payload that carves out some DRAM for the Secure world, 
>>> and the BSP U-Boot has some hard-coded handling for that whereas mainline 
>>> doesn't. As a result, in that configuration Linux ends up unaware that some 
>>> of the memory it's been told about isn't actually accessible and will 
>>> trigger an external abort if touched (which due to the nature of the page 
>>> allocator typically only seems to happen under memory pressure, like a large 
>>> copy operation that churns a lot of data through the page cache).
>>>
>>> Robin.
>> Yes, I'm using the mini-loader from Rockchip and the trusted.img with the 
>> mainline uboot 2020.4
>> and what you tell me makes sense!
>>
>> I tried to use the open-source only but failed end up with:
>> "Try booting from MMC1"
>> and then timeout on the SD & eMMC, I think the clock not come up
>> or isn't initialized in the SPL.
>>
>> UBOOT config:
>>   List of device tree properties to drop for SPL:
>> ... clock-names .. assigned-clocks assigned-clock-rates assigned-clock-parents
>>
>> while I write this, I read about the "u-boot,dm-pre-reloc" in the help text - 
>> hmm
>> let me add this to the rk3399-orangepi.dts and give the pure open-source 
>> solution
>> one more try.
>
> I do recall having to do some fiddling to get TPL/SPL to boot from eMMC 
> reliably on my NanoPC-T4 - the only change I have committed locally is adding 
> a "u-boot,spl-boot-order" property, but I can't now remember whether the image 
> I'm currently using had any further temporary hacks on top of that.
>
> An alternative workaround is just to hack the kernel DT to explicitly reserve 
> the offending region - until I got mainline TPL/SPL and Trusted Firmware 
> working, this is what I had:
>
>     reserved-memory {
>         #address-cells = <2>;
>         #size-cells = <2>;
>         ranges;
>
>         external-abort@8400000 {
>             reg = <0 0x8400000 0 0x1200000>;
>             no-map;
>         };
>     };
>
> Robin. 
That's a good workaround, and buy me some time until I found a proper solution.
I'd saw the "u-boot,spl-boot-order" in the other *-u-boot.dtsi files and add it 
to my
solution. But all I got is
Try to boot from MMC2
and then a mmc_init error -95 (no response from the sd/emmc)

I wait for my new prototypes, rk3399 + LPDDR4 .. lets hope that it will be boot 
better then the Orange-pi.

Thank you for your help.

Chris


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: arm64: el1_error when copy rawdata to a partition

[Chris Ruehl]

On 12/6/2020 10:43 am, Chris Ruehl wrote:
> On 11/6/2020 7:38 pm, Robin Murphy wrote:
>> On 2020-06-11 03:21, Chris Ruehl wrote:
>>> Hi Robin,
>>>
>>> On 10/6/2020 7:58 pm, Robin Murphy wrote:
>>>> Hi Chris,
>>>>
>>>> On 2020-06-10 04:49, Chris Ruehl wrote:
>>>>> Hi,
>>>>>
>>>>> just hit a panic on my rk3399-orangepi while running
>>>>>
>>>>> xz -d -c image.xz | dd of=/dev/mmcblk2p2 bs=1M
>>>>>
>>>>> This can reproduce.
>>>>
>>>> What's your firmware setup? There's a known snag when mixing mainline 
>>>> U-Boot with Rockchip's Trusted Firmware binaries - the "trust.img" blobs 
>>>> tend to include an OP-TEE payload that carves out some DRAM for the Secure 
>>>> world, and the BSP U-Boot has some hard-coded handling for that whereas 
>>>> mainline doesn't. As a result, in that configuration Linux ends up unaware 
>>>> that some of the memory it's been told about isn't actually accessible and 
>>>> will trigger an external abort if touched (which due to the nature of the 
>>>> page allocator typically only seems to happen under memory pressure, like a 
>>>> large copy operation that churns a lot of data through the page cache).
>>>>
>>>> Robin.
>>> Yes, I'm using the mini-loader from Rockchip and the trusted.img with the 
>>> mainline uboot 2020.4
>>> and what you tell me makes sense!
>>>
>>> I tried to use the open-source only but failed end up with:
>>> "Try booting from MMC1"
>>> and then timeout on the SD & eMMC, I think the clock not come up
>>> or isn't initialized in the SPL.
>>>
>>> UBOOT config:
>>>   List of device tree properties to drop for SPL:
>>> ... clock-names .. assigned-clocks assigned-clock-rates assigned-clock-parents
>>>
>>> while I write this, I read about the "u-boot,dm-pre-reloc" in the help text 
>>> - hmm
>>> let me add this to the rk3399-orangepi.dts and give the pure open-source 
>>> solution
>>> one more try.
>>
>> I do recall having to do some fiddling to get TPL/SPL to boot from eMMC 
>> reliably on my NanoPC-T4 - the only change I have committed locally is adding 
>> a "u-boot,spl-boot-order" property, but I can't now remember whether the 
>> image I'm currently using had any further temporary hacks on top of that.
>>
>> An alternative workaround is just to hack the kernel DT to explicitly reserve 
>> the offending region - until I got mainline TPL/SPL and Trusted Firmware 
>> working, this is what I had:
>>
>>     reserved-memory {
>>         #address-cells = <2>;
>>         #size-cells = <2>;
>>         ranges;
>>
>>         external-abort@8400000 {
>>             reg = <0 0x8400000 0 0x1200000>;
>>             no-map;
>>         };
>>     };
>>
>> Robin. 
> That's a good workaround, and buy me some time until I found a proper solution.
> I'd saw the "u-boot,spl-boot-order" in the other *-u-boot.dtsi files and add 
> it to my
> solution. But all I got is
> Try to boot from MMC2
> and then a mmc_init error -95 (no response from the sd/emmc)
>
> I wait for my new prototypes, rk3399 + LPDDR4 .. lets hope that it will be 
> boot better then the Orange-pi.
>
> Thank you for your help.
>
> Chris

The definition for 0x8400000 in the DT works for me.

[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000200000-0x00000000083fffff]
[    0.000000]   node   0: [mem 0x0000000009600000-0x000000007fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000200000-0x000000007fffffff]

no more crash.

Thanks Robin!

Cheers
Chris

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel