| Message ID | 20130908121027.GB360@x4 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Sep 8, 2013 at 2:10 PM, Markus Trippelsdorf <markus@trippelsdorf.de> wrote: > kexec calls: > printk(KERN_EMERG "Starting new kernel\n"); > late before calling machine_shutdown(). > However at this point the underlying fb device may have already been > shutdown. This causes the kernel to hang. > Fix by simply getting rid of the printk call. > > Signed-off-by: Markus Trippelsdorf <markus@trippelsdorf.de> Shouldn't this be taken care of with the suspend/resume_console calls? At least that's my understanding how it works in the suspend/hibernate code, maybe kexec needs similar treatment ... -Daniel
On Sun, 08 September 2013 Daniel Vetter <daniel@ffwll.ch> wrote: > On Sun, Sep 8, 2013 at 2:10 PM, Markus Trippelsdorf > <markus@trippelsdorf.de> wrote: > > kexec calls: > > printk(KERN_EMERG "Starting new kernel\n"); > > late before calling machine_shutdown(). > > However at this point the underlying fb device may have already been > > shutdown. This causes the kernel to hang. > > Fix by simply getting rid of the printk call. > > > > Signed-off-by: Markus Trippelsdorf <markus@trippelsdorf.de> > > Shouldn't this be taken care of with the suspend/resume_console calls? > At least that's my understanding how it works in the suspend/hibernate > code, maybe kexec needs similar treatment ... Is it suspend/resume_console? Shouldn't the fbcon be short-circuited or disabled once there is no more underlying fb? Serial console, if present, as well as netconsole if network device is still alive should continue working I would say. Bruno > -Daniel
diff --git a/kernel/kexec.c b/kernel/kexec.c index 59f7b55..f33fa9f 100644 --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -1679,7 +1679,6 @@ int kernel_kexec(void) #endif { kernel_restart_prepare(NULL); - printk(KERN_EMERG "Starting new kernel\n"); machine_shutdown(); }
kexec calls: printk(KERN_EMERG "Starting new kernel\n"); late before calling machine_shutdown(). However at this point the underlying fb device may have already been shutdown. This causes the kernel to hang. Fix by simply getting rid of the printk call. Signed-off-by: Markus Trippelsdorf <markus@trippelsdorf.de> --- kernel/kexec.c | 1 - 1 file changed, 1 deletion(-)