There is a problem related to the setup of the Linux awareness if:
All or some awareness windows (e.g. TASK.DTask, TASK.Process) show errors or are hatched.
Current task cannot be displayed after Linux has booted, and the target has been stopped: "(task error)" or "(other)". The space-id 0xFFFF is displayed in the List window
Check the kernel configuration. The problem is e.g. often caused a missing kernel configuration “Compile the kernel with debug info” (CONFIG_DEBUG_INFO) or by the kernel configuration "Reduce debugging information" (CONFIG_DEBUG_REDUCED). Refer for more information to the chapter “Kernel Configuration” in Training Linux Debugging.
Try to disable the translation with TRANSlation.OFF. If you get better results, then the problem is related to wrong translation settings. Auto-detection scripts are available for Arm and Arm64 under:
Please read the script header carefully.
Contact the technical support by opening a new ticket if this script returns an error.
Check if the loaded vmlinux matches the executed kernel binary:
Get the target Linux banner by execution the command cat /proc/version in the terminal window
Load the vmlinux file including code into the debugger virtual memory with Data.LOAD.Elf vmlinux AVM:0 /NoSymbol
Dump the linux_banner from loaded vmlinux: Data AVM:linux_banner /NoHex /NoOrient
Compare both strings including timestamps
Note: in some cases the symbols may not be matching even if the Linux banner comparison shows the same string. A typical example is caused by the fact that OpenEmbedded / bitbake may compile multiple kernel variants in the same folder. Each result file is moved to a deploy folder - typically the build step will add a postfix if there are multiple variants of the same file. e.g. `Image-5.10-minimal`, `Image-5.10-xen`,... This is however not done for the `vmlinux` file of the respective build run. What can happen for instance is that the kernel is build once and later on the `initrd` is embedded.
Another pitfall that typically applies to all kernel symbols is - with Linux 5.9 the `0x80000` offset got removed from the kernel. But some bootloaders still start the kernel with an `0x80000` offset. This will trigger a relocation of the kernel to the next properly aligned address up/down.
Refer for more information to Training Linux Debugging.