LKML Archive on
help / color / mirror / Atom feed
From: Vivek Goyal <>
To: Tomasz Chmielewski <>
Cc: LKML <>,
	Kexec Mailing List <>,
	Horms <>
Subject: Re: why kexec insists on syncing with recent kernels?
Date: Thu, 7 Feb 2008 11:37:52 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Feb 07, 2008 at 03:13:30PM +0100, Tomasz Chmielewski wrote:
> According to kernel/kexec.c:
>  * kexec does not sync, or unmount filesystems so if you need
>  * that to happen you need to do that yourself.

In latest kexec code I do see it syncing. But it does not unmount the
filesystems. So this comment looks like partially wrong.

> I saw this was true with 2.6.18 kernel (i.e., it didn't sync), but kexec 
> syncs with recent kernels (I checked and 2.6.24):
> # kexec -e
> md: stopping all md devices
> sd 2:0:0:0: [sdb] Synchronizing SCSI cache

Which kexec-tools you are using? 

syncing is initiated by user space so changing kernel will not have
any effect (as long as user space is same). I think just that message
are spitted by kernel, so probably 2.6.18 did not spit any message and
2.6.24 does.

> With kexec on 2.6.18 it was executing a loaded kernel immediately.
> Generally, it's a good thing to sync before jumping into a new kernel, but 
> it breaks my setup here after upgrading from 2.6.18 to 2.6.24.
> Why?
> I have a couple of diskless (iSCSI-boot) machines with a buggy BIOS (old 
> Supermicro P4SBR/P4SBE) which randomly freeze after rebooting (the machine 
> shuts down just fine, but instead of booting again, showing BIOS bootup 
> messages etc. you can just see blank screen).
> Therefore, I use kexec as a workaround for this rebooting problem.
> The way kexec works now makes rebooting unreliable again:
> - network interfaces are brought down,
> - kernel tries to sync - it never will, as we're booted off network, which 
> is down

Kexec has got an option -x --no-ifdown, which will not bring the network
down. Try that. "kexec- -e -x"

> Any ideas why kexec insists on syncing?

To me it makes sense. Just making sure that cache changes make to the file
system before you boot into new kernel.

In latest kexec-tools, I do see sync() is done first and then network
interfaces are brought down. 

Try latest kexec tools from:

and see if it works fine for you.


  reply	other threads:[~2008-02-07 16:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-07 14:13 Tomasz Chmielewski
2008-02-07 16:37 ` Vivek Goyal [this message]
2008-02-07 16:59   ` Tomasz Chmielewski
2008-02-08 16:04     ` Vivek Goyal
2008-02-08 17:04       ` Randy Dunlap
2008-02-08 17:19         ` Tomasz Chmielewski
2008-02-08 17:26           ` Vivek Goyal
2008-02-11 12:36           ` Geert Uytterhoeven
2008-02-08  8:53 ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: why kexec insists on syncing with recent kernels?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).