From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruno =?UTF-8?B?UHLDqW1vbnQ=?= Subject: Re: [PATCH 1/3] kexec: get rid of late printk Date: Sun, 8 Sep 2013 22:42:49 +0200 Message-ID: <20130908224249.61a866ed@neptune.home> References: <20130908120947.GA360@x4> <20130908121027.GB360@x4> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "kexec" Errors-To: kexec-bounces+glkk-kexec=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Daniel Vetter Cc: dri-devel , kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Eric Biederman , Markus Trippelsdorf List-Id: dri-devel@lists.freedesktop.org On Sun, 08 September 2013 Daniel Vetter wrote: > On Sun, Sep 8, 2013 at 2:10 PM, Markus Trippelsdorf > 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 > > 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