-
Notifications
You must be signed in to change notification settings - Fork 173
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
I2C: trace IRQ status on panic #1666
Conversation
IIUC the notification mask for a controller should only ever be one-hot, so the for loop isn't necessary.
#[count(skip)] | ||
Panic(Register, u32), | ||
#[count(skip)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added #[count(skip)]
to the ringbuf entries that are only recorded on panics, since we don't really care about counting them --- they'll either be counted exactly the number of times we record them in the panic code, or they'll never be recorded at all. So, I figured it was worth saving the 8 bytes we can shave off by not generating counters for these.
@@ -37,7 +37,6 @@ name = "drv-stm32xx-i2c-server" | |||
stacksize = 1048 | |||
features = ["h743"] | |||
priority = 2 | |||
max-sizes = {flash = 16384, ram = 4096} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We hit the flash size limit for the I2C server task, and @cbiffle said it would be fine to just remove the limits so that we don't have to keep playing guess-a-number forever.
Using the
irq_status
system call I added in #1661, we can extend thepanic function added to
stm32xx-i2c
in #1657 to also include the stateof any IRQs currently mapped to its notification mask. This way, if an
I2C driver panics, we can also include the kernel's understanding of its
IRQ state in the dump.