Messages in this thread | | | Date | Mon, 16 Oct 2017 10:15:47 -0400 | From | Steven Rostedt <> | Subject | Re: NMI watchdog dump does not print on hard lockup |
| |
On Mon, 16 Oct 2017 22:13:05 +0900 Sergey Senozhatsky <sergey.senozhatsky@gmail.com> wrote:
> just "brainstorming" it... with some silly ideas. > > pushing the data from NMI panic might look like we are replacing one > deadlock scenario with another deadlock scenario. some of the console > drivers are soooo complex internally. so I have been thinking about... > may be we can extend struct console and add ->write_on_panic() and that > handler must be as lockless as possible; so lockless that calling it > from anything that is not panic() is a severe bug.
This may not be a bad idea. And make it so it can't be called unless we are in panic mode (or at least "oops in progress").
If oops_in_progress is set, and the console has a "write_on_panic" handler, then just call that.
Heck, if it doesn't have one, and early_printk is defined, then perhaps that should be the default "write_on_panic" output?
-- Steve
> > an absolutely trivial case, > if serial console does > > console_write_cb(struct console *co, const char *s, unsigned int count) > { > spin_lock_irqsave(&port->lock, flags); > uart_console_write(s, count, console_putchar); > spin_unlock_irqrestore(&port->lock, flags); > } > > then panic callback can look like > > console_write_on_panic_cb(struct console *co, const char *s, unsigned int count) > { > /* no, we don't take the port lock here */ > uart_console_write(s, count, console_putchar); > } > > a less trivial case might look more involved. but in general that > write_on_panic() callback must do the absolute minimum of work. so > it's sort of a early console, but as part of normal console driver. > > I also got some other serial console crazy ideas, but they are not > related to this topic. > > -ss
| |