LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Tomasz Chmielewski <mangoo@wpkg.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Kexec Mailing List <kexec@lists.infradead.org>,
	Horms <horms@verge.net.au>
Subject: Re: why kexec insists on syncing with recent kernels?
Date: Fri, 8 Feb 2008 09:04:07 -0800	[thread overview]
Message-ID: <20080208090407.4ab240f1.randy.dunlap@oracle.com> (raw)
In-Reply-To: <20080208160408.GB18782@redhat.com>

On Fri, 8 Feb 2008 11:04:08 -0500 Vivek Goyal wrote:

> 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 2.6.23.14 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) {
>                 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.

I'm seeing NFS mounts take forever to unmount (at shutdown/reboot).
(forever => 1 hour ... or never completes)

Is this similar to the problem that the OP is asking about?


---
~Randy

  reply	other threads:[~2008-02-08 17:18 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
2008-02-08 17:04       ` Randy Dunlap [this message]
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20080208090407.4ab240f1.randy.dunlap@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mangoo@wpkg.org \
    --cc=vgoyal@redhat.com \
    --subject='Re: why kexec insists on syncing with recent kernels?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).