Hi all, I am looking into random lockups - significantly rarer than once a day in typical usage, various patterns like lots of bursty network traffic increase frequency - that affect both the uEVM and the Pyra (also OMAP5432 based) on newer kernels (currently testing with 5.6 but I have seen lockups with 5.7 too). Currently I'm working with the uEVM as it is a bit easier to connect the JTAG adapter. I managed to get a lockup with the JTAG attached, and unfortunately the processor is badly locked up enough (presumably a stuck memory bus?) that JTAG isn't able to get a register dump or stacktrace. But I do get the following error which at least gives a PC: CortexA15_0: Trouble Halting Target CPU: (Error -1323 @ 0xC0223E0C) Device failed to enter debug/halt mode because pipeline is stalled. Power-cycle the board. If error persists, confirm configuration and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.0.00002) The second core is just sitting at WFI, don't think there is anything suspicious about that. Looking at the kernel disassembly this is the actual register read (ldr r0, [r1]) part of omap4_prminst_read_inst_reg. My best guess is that it is trying to read from a register that doesn't exist or isn't responding due to the current power configuration, but I wonder if anyone has seen this before or has any more clues on how to debug this? It's a shame that I can't seem to see what r1 is or get a backtrace. It looks like it might be possible to set some kind of timeout on the interconnect, has anyone tried something like that to debug this kind of issue? Best David Shah
