[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANq1E4Qfohv7A-rcGVb6pc5rRffWsef4FkXButSJUkYxz9qkng@mail.gmail.com>
Date: Tue, 6 May 2014 15:53:32 +0200
From: David Herrmann <dh.herrmann@...il.com>
To: Takashi Iwai <tiwai@...e.de>
Cc: Daniel Vetter <daniel@...ll.ch>,
dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Atomicity in KMS panic notifier
Hi
On Tue, May 6, 2014 at 3:38 PM, Takashi Iwai <tiwai@...e.de> wrote:
> At Tue, 6 May 2014 15:32:21 +0200,
> David Herrmann wrote:
>> fbcon is called through the VT or fbdev layer, which is called by
>> bust_spinlocks(1) via either unblank_screen() or console_unblank().
>
> You mean bust_spinlocks(0), right?
>
> void __attribute__((weak)) bust_spinlocks(int yes)
> {
> if (yes) {
> ++oops_in_progress;
> } else {
> #ifdef CONFIG_VT
> unblank_screen();
> #endif
> console_unblank();
> if (--oops_in_progress == 0)
> wake_up_klogd();
> }
> }
>
> bust_spinlocks(0) is called after the notifier chain, and it's almost
> at the end of panic().
Yes, it's called _after_ the panic-handlers but _before_
console_unlock() (see console_unblank() in printk.c). Therefore, we
call into set_config() before the serial drivers get the panic-message
(flushed via console_unlock()). If the serial drivers (or whatever you
use for debugging) register their own panic-handlers, then they're
fine of course.
Thanks
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists