At Tue, 6 May 2014 15:32:21 +0200, David Herrmann wrote: > > Hi > > On Tue, May 6, 2014 at 3:27 PM, Takashi Iwai <tiwai@xxxxxxx> wrote: > > At Mon, 5 May 2014 16:52:45 +0200, > > Daniel Vetter wrote: > >> > >> On Mon, May 5, 2014 at 4:48 PM, Takashi Iwai <tiwai@xxxxxxx> wrote: > >> > > >> > The current problem I see is that the rest of panic notifier chain > >> > won't be called once when we hit the problem in KMS notifier. So, > >> > this bug in KMS influences on the rest panic behavior. > >> > > >> > Maybe a hackish solution would be to keep KMS notifier at the end of > >> > notifier chain so that it crashes at last. I don't like this either, > >> > but... > >> > >> You need to do that with both the kms panic notifier in > >> drm_fb_helper.c and with the fbcon panic notifier. And iirc there's > >> also a console->unblank call somewhere which _also_ can end up in > >> ->set_par. But I'm not sure anymore when exactly that one is run, I've > >> tried hard to forget this all ;-) > > > > Looking back at the code again, it seems that fbcon has no panic > > notifier. It has own notifier chain, but it's a private chain that > > isn't called by the panic. So, we can forget about fbcon, at least (I > > hope). > > 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(). Takashi _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel