From: Vivek Goyal <vgoyal@redhat.com>
To: dmitry.krivenok@emc.com
Cc: Kexec Mailing List <kexec@lists.infradead.org>
Subject: Re: kdump and SMP system kernel
Date: Mon, 15 Aug 2011 10:40:30 -0400 [thread overview]
Message-ID: <20110815144030.GD10154@redhat.com> (raw)
In-Reply-To: <9C7BACB01B839A499792154E76C9ADE555DE65CE87@MX19A.corp.emc.com>
On Mon, Aug 15, 2011 at 10:27:30AM -0400, dmitry.krivenok@emc.com wrote:
> Hello Vivek and Maneesh,
> I've read your document Documentation/kdump/kdump.txt and built system and dump-capture
> kernels with the options mentioned there.
>
> Then I booted the new system kernel and registered a "panic handler" using the following command
> kexec -p /boot/linux-3.0.0-capture --initrd=/boot/initrd-3.0.0-capture --append="root=/dev/mapper/myvg-root 3 irqpoll maxcpus=1 reset_devices"
>
> Finally, I simulated a panic using
> echo c > /proc/sysrq-trigger
>
> Unfortunately, the dump-capture kernel wasn't functional (it was booting very slowly, I saw lots of messages
> like "ata2: lost interrupt", my keyboard didn't work at all and I couldn't access the system via the network).
>
> I investigated this problem and tried lots of combinations of boot parameters for dump-capture kernel, but
> nothing helped. Then I tried to tune boot parameters of system kernel and found that if I specify "maxcpus=1"
> for system kernel, then dump-capture kernel always boots successfully and I have access to correct /proc/vmcore.
>
> The problem is that I'm debugging a problem which only occurs on SMP kernel and I never see it on the kernel
> booted with "maxcpus=1".
>
> So I just want to clarify - is it possible to use kexec/kdump with SMP system kernel?
> Is it intended to work at all?
>
> Thanks in advance!
>
> P.S.
> I'm using Arch Linux with vanilla kernel 3.0.0 and kexec-tools 2.0.2-3 running in VM on VmWare ESX server.
Yes it is supposed to work on SMP machines. maxcpus=1 in second kernel
will make sure that it brings up only the cpu we crashed on. You can
also try using nr_cpus=1 on latest kernels.
It sounds like an issue with disk driver initialization and could have
something do to with hypervisor also. Not sure. Does it work on bare
metal.
P.S. Maneesh is no more with IBM so above id is not valid. I am not sure
what's new id. Some of these issues you can copy on kexec-tools mailing
list. I am ccing the list now.
Thanks
Vivek
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next parent reply other threads:[~2011-08-15 14:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9C7BACB01B839A499792154E76C9ADE555DE65CE87@MX19A.corp.emc.com>
2011-08-15 14:40 ` Vivek Goyal [this message]
2011-08-15 14:56 ` kdump and SMP system kernel dmitry.krivenok
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=20110815144030.GD10154@redhat.com \
--to=vgoyal@redhat.com \
--cc=dmitry.krivenok@emc.com \
--cc=kexec@lists.infradead.org \
/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.