At Tue, 6 May 2014 15:53:32 +0200, David Herrmann wrote:
Hi
On Tue, May 6, 2014 at 3:38 PM, Takashi Iwai tiwai@suse.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 for clarification. I see it's at the sensible place.
FWIW, the problem I'm tackling now is the blockage of other panic notifiers due to drm_fb. For example, pvpanic isn't executed reliably because of this when a KMS (either cirrus or qxl) driver is loaded. So, for me, it's fine that the system stalls after that point :)
Takashi