-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Xtensa Multi-core critical-section is not sound(?) #1171
Comments
@bugadani sorry for the ping, but do you have any ideas on this one? |
Someone broke this assumption |
Oh this fn get_raw_core() -> usize {
((xtensa_lx::get_processor_id() as usize & 0x2000) != 0) as usize
} will very likely produce a value of 1 |
Git blaming that line points me to this PR: #1126 I'm not sure what the crash was? I don't see an issue associated with it. |
IIRC there was a discussion in the Matrix channel - ah yes ... there it is: https://matrix.to/#/!LdaNPfUfvefOLewEIM:matrix.org/$LXNqhvjxecSQlJFK-mmJCIYYJ_fgStulDsr5r1mNb-o?via=matrix.org&via=tchncs.de&via=mozilla.org |
Oops, it's me :P |
I'm currently debugging a weird issue on the ESP32S3 with embassy multi-core related to critical section, as it seems like it tries to double-unlock the
MULTICORE_LOCK
from different threads when using the embassy executor and I'm not entirely sure why it happens.What seems to happen:
set_alarm
for the executor poll (Seems to be on thread_id=1, token=4294967295)set_alarm
it aquires acritical_section
, and at the end attempts to drop ittime_driver_timg.rs
EmbassyTimer::on_interrupt
EmbassyTimer::on_interrupt
aquires it's owncritical_section
and when it tries to drop the owner isn'tthread_id()
(thread_id seems to be 0 at this stack frame).I'm not sure how it's possible to have 2 threads in one call stack, but it seems like thread_1 unlocks, and before finishing the sync thread_0 locks, causing thread_1 to overwrite the owner. Let me know if I'm missing something
The text was updated successfully, but these errors were encountered: