• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 629 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

TDA4VM: How to insure data consistency in cache?

TDA4VH-Q1: Kernel panic when doing atomic compare-exchange operation on physical memory

Matthias Schellhase
Prodigy 41 points

Part Number: TDA4VH-Q1

Hi,

I am currently running into Kernel panics when I want to do a atomic compare-exchange operation on specific memory addresses.
This happens both on DDR and on MSMC-SRAM. The memory-addresses are properly carved-out in the device-tree and aligned.
Crashes happen both when using memory-mapped /dev/mem from user space or accessing raw iomap'ed memory from Kernel space.

I think the problematic assembler instructions are LDARX / STLXR.

Any hints what I should investigate?

Here is a dump of the Kernel panic:

[12360.523401] SError Interrupt on CPU2, code 0x00000000bf000002 -- SError
[12360.523415] CPU: 2 PID: 669 Comm: devmem2 Not tainted 6.1.46-rt13-00085-gfea3501294f9-dirty #1 25c60401117e7ee7ce43f409e60b80442b2b75dd
[12360.523423] Hardware name: basic-2 (J784S4) (DT)
[12360.523425] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[12360.523429] pc : el0_da+0x2c/0xcc
[12360.523446] lr : el0t_64_sync_handler+0xd4/0x150
[12360.523452] sp : ffff80000c0cbe80
[12360.523454] x29: ffff80000c0cbe80 x28: ffff0008012b8000 x27: 0000000000000000
[12360.523461] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[12360.523466] x23: 0000000060000000 x22: 0000aaaaad0413b8 x21: 00000000ffffffff
[12360.523470] x20: ffff800805de2000 x19: ffff80000c0cbeb0 x18: ffff80000a55d010
[12360.523474] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[12360.523479] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
[12360.523483] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
[12360.523487] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
[12360.523490] x5 : 0000000000000000 x4 : ffff80000c0cbeb0 x3 : 0000000000000000
[12360.523494] x2 : ffff0008012b8000 x1 : 000000009200004f x0 : 0000ffff93aed000
[12360.523499] Kernel panic - not syncing: Asynchronous SError Interrupt
[12360.523503] CPU: 2 PID: 669 Comm: devmem2 Not tainted 6.1.46-rt13-00085-gfea3501294f9-dirty #1 25c60401117e7ee7ce43f409e60b80442b2b75dd
[12360.523506] Hardware name: basic-2 (J784S4) (DT)
[12360.523508] Call trace:
[12360.523510]  dump_backtrace.part.0+0x110/0x11c
[12360.523517]  show_stack+0x24/0x50
[12360.523520]  dump_stack_lvl+0x68/0x9c
[12360.523524]  dump_stack+0x1c/0x48
[12360.523528]  panic+0x184/0x364
[12360.523533]  add_taint+0x0/0xf0
[12360.523537]  arm64_serror_panic+0x7c/0x90
[12360.523541]  do_serror+0x78/0x7c
[12360.523543]  el1h_64_error_handler+0x34/0x60
[12360.523548]  el1h_64_error+0x64/0x68
[12360.523551]  el0_da+0x2c/0xcc
[12360.523555]  el0t_64_sync_handler+0xd4/0x150
[12360.523559]  el0t_64_sync+0x194/0x198
[12360.710345] SMP: stopping secondary CPUs
[12360.710354] Kernel Offset: disabled
[12360.710356] CPU features: 0x40000,20028084,0000420b
[12360.710359] Memory Limit: none

I am implementing a lock-free queue to exchange data between A72 and R5F cores.
Accessing the same memory regions from R5F side works fine. Also atomic compare-exchange works fine here.

Regards,
Matthias

  • 0 in reply to Keerthy J
    Prodigy 41 points

    Hi Keerthy,

    thanks for the link. The issue looks quite similar, however, in my case I have a fully booted Linux system. The problem does not occur on standard virtual memory. 

    After changing the MPU config on the R5F to non-cacheable, I am also running here into the data abort handler.

            {
            /* Region 10 configuration:
             * Lock-free queue on DDR RAM
             */
            .regionId = 10u,
            .enable = 1u,
            .baseAddr = 0xAF000000u,
            .size = CSL_ARM_R5_MPU_REGION_SIZE_16MB,
            .subRegionEnable = CSL_ARM_R5_MPU_SUB_REGION_ENABLE_ALL,
            .exeNeverControl = 0u,
            .accessPermission = CSL_ARM_R5_ACC_PERM_PRIV_USR_RD_WR,
            .shareable = 1u,
            .cacheable = (uint32_t)FALSE,
            .cachePolicy = CSL_ARM_R5_CACHE_POLICY_NON_CACHEABLE,
            .memAttr = 0u,
        },
     

    Again, same behavior on both SRAM and DDR. At least, the problem seems now consistent.

    Thanks,
    Matthias

  • +1 in reply to Matthias Schellhase
    TI__Mastermind 26035 points

    Exclusive operations are undefined when executed on non-normal memory attribute types (like DEVICE or StronglyOrdered).  The other thread hit this pre-boot as the loader didn't have memory setup generically. The post boot setup you describe is likely non-standard also and is getting aborts for the same reason. The exclusives are used in SMP Linux between cores and clusters but that is mostly handed by local monitors in the A72 and coherency logic between clusters. Outside of that cross a72 scope (which is handled for inner-shared+copy-back-cache) these operations will not any special effect for normal-non-cached types between cores as there is no external monitors in place. Other cross core synchronization methods should be used like those built into high level apis in rpmsg, or if you want lower level using hw-spinlock or mailboxes.