Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add a "panic" command to process console #2528

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Apr 21, 2021
Merged

Add a "panic" command to process console #2528

merged 1 commit into from
Apr 21, 2021

Conversation

bradjc
Copy link
Contributor

@bradjc bradjc commented Apr 9, 2021

Pull Request Overview

This pull request is supposed to be just adding a "panic" command to process console so that users can force a panic, and more importantly the debug information that comes along with it. This is a stop-gap if we can instead use the process console to display the per-process debug info without a full kernel panic someday.

Unfortunately, on the board I want to use this on (the nano33ble), just doing a normal panic!() in process console doesn't work. The issue is that process console commands are parsed in a UART TX done callback (which on the nano33 originates from the CDC/USB stack). Since panic changes the control flow immediately, the TX done callback never finishes returning down the callback chain, and the USB driver's state is effectively corrupted.

So, this implementation uses a deferred call so that the panic runs on a different callback. This makes it work on the nano33ble, but adds a deferred call for every process console user.

Testing Strategy

Using it on the nano33ble.

TODO or Help Wanted

I don't like this solution (hence why no other boards compile since I only fixed up the nano33ble). Any thoughts on a better way to handle this? Some possible options:

  1. Use this approach, and implement for all boards that use process console.
  2. Make the deferred call an Option<>, and just immediately panic for boards that use a None.
  3. Try to hack the panic implementation in nano33ble/io.rs to cleanup the state that wasn't cleaned up if the panic happens in a UART callback.

Documentation Updated

  • Updated the relevant files in /docs, or no updates are required.

Formatting

  • Ran make prepush.

@phil-levis
Copy link
Contributor

TX done callback never finishes returning down the callback chain, and the USB driver's state is effectively corrupted.

This sounds like a bug in the USB driver? The stack should be in a well-defined state in the callback. I'll try to take a look.

@alistair23
Copy link
Contributor

I'm not a fan of a userspace process being able to panic the kernel

@hudson-ayers
Copy link
Contributor

I'm not a fan of a userspace process being able to panic the kernel

The process console is not a userspace process, it is a privileged (and optional) kernel capsule that directly exposes a console interface over a serial connection. It is present even if no userspace processes exist on the board. It also provides the ability for a user to start/stop/fault arbitrary processes, which seems about as dangerous as being able to panic the kernel

@alistair23
Copy link
Contributor

Ah, you are right

In which case option 3 might be the best option. I feel like Tock should be able to handle a panic call anywhere, even inside the USB stack. If that isn't feasible though then option 2 seems like the next best bet.

@hudson-ayers
Copy link
Contributor

I tested this out some, and even with the changes in this PR I do not always see panic prints complete -- they often stop after 3 or 4 buffers. Somewhat separately, I think that the enable_interrupts() and disable_interrupts() lines in usbd.rs::handle_interrupt() should be removed (

tock/chips/nrf52/src/usbd.rs

Line 1133 in 1c2bcbe

self.disable_all_interrupts();
). Given how Tock handles interrupts, I do not think there is any benefit to disabling interrupts in an interrupt handler, as the interrupts of concern have already been disabled at the NVIC granularity in

tock/arch/cortex-m/src/lib.rs

Line 150 in 1c2bcbe

// Now need to disable the interrupt that fired in the NVIC to ensure it

@bradjc
Copy link
Contributor Author

bradjc commented Apr 19, 2021

This works ok on the nano33ble if no processes are using the console, however, it seems to not print all of the panic information reliably if I have, say, the hello_loop test installed. So, the complexity of the deferred call is probably not worth it if it doesn't even work reliably on the board that inspired it.

@hudson-ayers
Copy link
Contributor

I was testing with hello_loop installed as well if I remember correctly. That sounds like something that might be good to dig into separately -- it seems possible the same issue could manifest for a normal kernel panic, depending on the state of the USB stack.

@hudson-ayers
Copy link
Contributor

Should we close this then?

@bradjc
Copy link
Contributor Author

bradjc commented Apr 19, 2021

I still would like to add the panic command.

@bradjc bradjc changed the title Add a "panic" command to process console, implemented with deferred call Add a "panic" command to process console Apr 20, 2021
@bradjc
Copy link
Contributor Author

bradjc commented Apr 20, 2021

Ok now this PR just adds the "panic" command.

@phil-levis
Copy link
Contributor

bors r+

@bors
Copy link
Contributor

bors bot commented Apr 21, 2021

Build succeeded:

@bors bors bot merged commit 92d5637 into master Apr 21, 2021
@bors bors bot deleted the pconsole-panic branch April 21, 2021 05:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@lschuermann lschuermann lschuermann approved these changes

@hudson-ayers hudson-ayers hudson-ayers approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
5 participants
@bradjc @phil-levis @alistair23 @hudson-ayers @lschuermann