On (10/16/17 10:15), Steven Rostedt wrote:
> On Mon, 16 Oct 2017 22:13:05 +0900
> Sergey Senozhatsky 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. s
On (10/16/17 10:15), Steven Rostedt 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 s complex internally. so
On Mon, 16 Oct 2017 22:13:05 +0900
Sergey Senozhatsky 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 s complex internally
Hello,
On (10/16/17 13:12), Petr Mladek wrote:
[..]
> > I think an NMI watchdog should just force the flush - the same way an
> > oops should. Deadlocks aren't really relevant if something doesn't get
> > printed out anyway.
>
> We expicititely flush the NMI buffers in panic() when there is
> not
On Fri 2017-10-13 12:12:29, Linus Torvalds wrote:
> On Fri, Oct 13, 2017 at 6:18 AM, Steven Rostedt wrote:
> >
> > Or add the following case: The watchdog triggers, does the print, then
> > if it triggers again in a certain amount of time, and the print still
> > hasn't been flushed, the flush hap
On Fri, Oct 13, 2017 at 6:18 AM, Steven Rostedt wrote:
>
> Or add the following case: The watchdog triggers, does the print, then
> if it triggers again in a certain amount of time, and the print still
> hasn't been flushed, the flush happens then.
By the time 40 sec has passed, I suspect most pe
On Fri, 13 Oct 2017 13:14:44 +0200
Petr Mladek wrote:
> In general, we could either improve detection of situations when
> the entire system is locked. It would be a reason to risk calling
> consoles even in NMI.
>
> Or we could accept that the "default" printk is not good for all
> situations a
On Thu 2017-10-12 12:16:58, Steven Rostedt wrote:
> static void lock_up_cpu(void *data)
> {
> unsigned long flags;
> raw_spin_lock_irqsave(&global_trace.start_lock, flags);
> raw_spin_lock(&global_trace.start_lock);
> raw_spin_unlock(&global_trace.start_lock);
> raw_sp
On Thu, Oct 12, 2017 at 12:16:58PM -0400, Steven Rostedt wrote:
> We need a way to have NMI flush to consoles when a lockup is detected,
> and not depend on an irq_work to do so.
Why do you think I never use that crap? early_printk FTW ;-)
While doing my presentation for ELC and OSS in Prague in a couple of
weeks, I notice an issue with the printk_safe logic. Then I wrote code
to see if my fears were justified.
I noticed that the NMI printks now depend on an irq_work to trigger to
flush the data out that was written by printks durin
10 matches
Mail list logo
