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: Fri, 8 Feb 2008 11:04:08 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Feb 07, 2008 at 05:59:14PM +0100, Tomasz Chmielewski wrote:
> Vivek Goyal schrieb:
>> 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? 
> # kexec -v
> kexec 1.101 released 15 February 2005
>> 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.
> Yes and no.
> I just booted 2.6.24 on a diskless system (Mandriva) I normally use with 
> 2.6.18 kernel, did kexec -e... And it executed the kernel immediately, 
> without any syncing.
> On Debian, with the same 2.6.24 kernel, it does sync.
> So what user space part does the syncing (and how to prevent it)?

Syncing is initiated by kexec-tools. Following is the code in
kexec/kexec.c in kexec-tools-testing.tar.gz

        if ((result == 0) && do_sync) {

I think this problem has nothing to do with syncing. There seems to be
some dependency on not shutting down network here. You might want to 
debug, exactly where does it get stuck.

- Specify earlyprintk= parameter for second kernel and see if control
  is reaching to second kernel.

- Otherwise specify --console-serial parameter on "kexec -l" commandline
  and it should display a message "I am in purgatory" on serial console.
  This will just mean that control has reached at least till purgatory.

Right now  there does not seem to be any option to prevent syncing and 
I don't know why would one like to have one.

> (...)
>>> 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"
> It does seem to help, thanks.
> Why it has to be the last option specified?

I have no idea. This might be an stale comment. Try putting -x before -e.

> I tried -f option before (don't call shutdown), but it didn't help.

Even if you did -f, it must have shutdown the network. I think somehow
in latest kernels there is some dependency on network and that's why
not shutting down network in this case is helping you.


  reply	other threads:[~2008-02-08 16:04 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
2008-02-07 16:59   ` Tomasz Chmielewski
2008-02-08 16:04     ` Vivek Goyal [this message]
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).