Nested panic with Core 0 #200

New Issue

mwojcik · 2022-09-02T12:22:56+08:00

mwojcik commented

2022-09-02 12:22:56 +08:00

Nested panics were already a thing before, but gained little attention since the file/line/message is much more readable and easier to trace.

Moving the print of the tuple above nested panic gave some insight:

Core 0 panic at runtime/src/main.rs:125:43: Could not set up RTIO PLL: "RTIO PLL failed to lock"
Backtrace: 
0x152368 0x159f30 0x15ba2c 0x10ec28 0x155848 0x193534 Core 0 panic at runtime/src/kernel/core1.rs:227:18: dl_unwind_find_exidx kernel image
nested panic!

Should that be run on Core 0 actually?

Obviously if there's no kernel loaded (it's a null pointer) it would panic there...

Nested panics were already a thing before, but gained little attention since the file/line/message is much more readable and easier to trace. Moving the print of the tuple above nested panic gave some insight: ``` Core 0 panic at runtime/src/main.rs:125:43: Could not set up RTIO PLL: "RTIO PLL failed to lock" Backtrace: 0x152368 0x159f30 0x15ba2c 0x10ec28 0x155848 0x193534 Core 0 panic at runtime/src/kernel/core1.rs:227:18: dl_unwind_find_exidx kernel image nested panic! ``` Should that be run on Core 0 actually? Obviously if there's no kernel loaded (it's a null pointer) it would panic there...

mwojcik referenced this issue

2022-09-02 14:53:51 +08:00

Soft panic for RTIO PLL reasons #199

sb10q referenced this issue

2022-10-05 17:20:11 +08:00

Soft panic for RTIO PLL reasons #199

mwojcik referenced this issue

2022-10-05 17:25:42 +08:00

Soft panic for RTIO PLL reasons #199

mwojcik commented

2022-10-10 16:20:46 +08:00

Poster

@sb10q

If there's no kernel loaded (and the kernel is not the cause of panic), it panics here again.

Why would it take the second branch of the if in this case? It should only unwind in the text section, so the condition &__text_start as *const u32 <= pc && pc < &__text_end as *const u32 should be true, isn't it?

Core 0 panic at runtime/src/main.rs:127:5: test panick
Backtrace: 
0x1298fc 0x12fee0 0x12fe44 0x12b73c 0x166484

Went a bit further into that, seems the last one is not within the text section. Added a quick workaround for that (do kernel lookup only on core 1, for core 0 it will be ignored) but that's gonna cut the backtrace short probably. Could that be the text section of the bootloader?

@sb10q > > If there's no kernel loaded (and the kernel is not the cause of panic), it panics here again. > > Why would it take the second branch of the ``if`` in this case? It should only unwind in the ``text`` section, so the condition `` &__text_start as *const u32 <= pc && pc < &__text_end as *const u32`` should be true, isn't it? ``` Core 0 panic at runtime/src/main.rs:127:5: test panick Backtrace: 0x1298fc 0x12fee0 0x12fe44 0x12b73c 0x166484 ``` Went a bit further into that, seems the last one is not within the ``text`` section. Added a quick workaround for that (do kernel lookup only on core 1, for core 0 it will be ignored) but that's gonna cut the backtrace short probably. Could that be the ``text`` section of the bootloader?

sb10q commented

2022-10-10 16:35:30 +08:00

The bootloader is in OCM and the runtime in SDRAM, so that should be easy to determine from the address ranges.

mwojcik commented

2022-10-10 17:01:57 +08:00

Poster

Alright, that's some leftover garbage, having added some additional debugging info, the last call to that function yields:

[     2.986782s]  INFO(runtime::kernel::core1): __text_start: 0x0 __text_end: 0x17bcb0 pc: 0x51205901

0x5120_5901 is within PL territory - would that mean libunwind is going one step too far?

Alright, that's some leftover garbage, having added some additional debugging info, the last call to that function yields: ``` [ 2.986782s] INFO(runtime::kernel::core1): __text_start: 0x0 __text_end: 0x17bcb0 pc: 0x51205901 ``` 0x5120_5901 is within PL territory - would that mean libunwind is going one step too far? ![image](/attachments/6013a12a-73b3-4f52-9854-4621d57e6d77)

image.png

16 KiB

mwojcik referenced this issue

2022-10-21 17:21:16 +08:00

Soft panic for RTIO PLL reasons #199

sb10q referenced this issue from a commit

2022-10-21 17:56:35 +08:00

enable network and mgmt during Rust panic, make RTIO PLL lock failure a panic

sb10q closed this issue

2022-10-21 17:57:04 +08:00

Sign in to join this conversation.