All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"arjan@infradead.org" <arjan@infradead.org>,
	Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Subject: boot hang: async vs. kexec
Date: Thu, 29 Jan 2009 13:15:20 -0800	[thread overview]
Message-ID: <49821C68.4000502@oracle.com> (raw)

I (try to) do daily build/boot testing.  The newly built kernel
is booted via kexec.  This was working until sometime between
2.6.28 and 2.6.29-rc1, so I bisected it.*

git bisect blames this commit:

96777fe7b042e5a5d0fe5fb861fcd6cd80ef9634 is first bad commit
commit 96777fe7b042e5a5d0fe5fb861fcd6cd80ef9634
Author: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Date:   Thu Jan 8 09:46:31 2009 -0600

    async: Don't call async_synchronize_full_special() while holding sb_lock
    
    sync_filesystems() shouldn't be calling async_synchronize_full_special
    while holding a spinlock.  The second while loop in that function is the
    right place for this anyway.


The new/kexec-loaded kernel hangs during initcalls.  The last one that
I can see (via netconsole, might miss a few of the very last lines) is:

calling  net_ns_init+0x0/0x14d @ 1
net_namespace: 1008 bytes
initcall net_ns_init+0x0/0x14d returned 0 after 0 usecs



Any ideas/suggestions?
Thanks.



*caveat: This was all done with the "don't use gcc 4.1.[01]
because it miscompiles __weak" patch reverted.  Could that
be an issue/problem here?  (I'm using gcc 4.1.1.)

-- 
~Randy


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"arjan@infradead.org" <arjan@infradead.org>,
	Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Subject: boot hang: async vs. kexec
Date: Thu, 29 Jan 2009 13:15:20 -0800	[thread overview]
Message-ID: <49821C68.4000502@oracle.com> (raw)

I (try to) do daily build/boot testing.  The newly built kernel
is booted via kexec.  This was working until sometime between
2.6.28 and 2.6.29-rc1, so I bisected it.*

git bisect blames this commit:

96777fe7b042e5a5d0fe5fb861fcd6cd80ef9634 is first bad commit
commit 96777fe7b042e5a5d0fe5fb861fcd6cd80ef9634
Author: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
Date:   Thu Jan 8 09:46:31 2009 -0600

    async: Don't call async_synchronize_full_special() while holding sb_lock
    
    sync_filesystems() shouldn't be calling async_synchronize_full_special
    while holding a spinlock.  The second while loop in that function is the
    right place for this anyway.


The new/kexec-loaded kernel hangs during initcalls.  The last one that
I can see (via netconsole, might miss a few of the very last lines) is:

calling  net_ns_init+0x0/0x14d @ 1
net_namespace: 1008 bytes
initcall net_ns_init+0x0/0x14d returned 0 after 0 usecs



Any ideas/suggestions?
Thanks.



*caveat: This was all done with the "don't use gcc 4.1.[01]
because it miscompiles __weak" patch reverted.  Could that
be an issue/problem here?  (I'm using gcc 4.1.1.)

-- 
~Randy


             reply	other threads:[~2009-01-29 21:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-29 21:15 Randy Dunlap [this message]
2009-01-29 21:15 ` boot hang: async vs. kexec Randy Dunlap
2009-01-29 22:28 ` Dave Kleikamp
2009-01-29 22:28   ` Dave Kleikamp
2009-01-29 23:34   ` Randy Dunlap
2009-01-29 23:34     ` Randy Dunlap

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=49821C68.4000502@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=arjan@infradead.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shaggy@linux.vnet.ibm.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.