From: Hariprasad Nellitheertha <hari@in.ibm.com>
To: Akinobu Mita <amgta@yacht.ocn.ne.jp>
Cc: Badari Pulavarty <pbadari@us.ibm.com>,
Andrew Morton <akpm@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
varap@us.ibm.com
Subject: Re: [PATCH] kdump: Fix for boot problems on SMP
Date: Fri, 26 Nov 2004 17:27:07 +0530 [thread overview]
Message-ID: <41A71A13.2010008@in.ibm.com> (raw)
In-Reply-To: <200411260221.49888.amgta@yacht.ocn.ne.jp>
Akinobu Mita wrote:
> On Tuesday 23 November 2004 09:43, Badari Pulavarty wrote:
>
>>gdb is not showing the stack info properly, on my saved vmcore.
>>I thought vmlinux is not matching the vmcore, so I verified that
>>vmcore and vmlinux matchup. But still no luck...
>>
>># gdb ../linux-2.6.9/vmlinux vmcore.2
>
>
> [...]
>
>
>>(gdb) bt
>>#0 default_idle () at arch/i386/kernel/process.c:108
>>#1 0xc04cdff8 in init_thread_union ()
>>#2 0xc0101b86 in cpu_idle () at arch/i386/kernel/process.c:196
>>#3 0xc04cea20 in start_kernel () at init/main.c:523
>>#4 0xc0100211 in L6 () at /tmp/cch2z2jk.s:2054
>>Cannot access memory at address 0x550007
>
>
>
> I think the panic was happened on the CPU except for CPU#0.
>
> Currently vmcore contains only CPU#0's register contents.
> Therefore, GDB always shows backtrace of CPU#0.
>
>
> fs/proc/vmcore.c:
>
> static void elf_vmcore_store_hdr(char *bufp, int nphdr, int dataoff)
> {
> ...
> /* 1 - Get the registers from the reserved memory area */
> reg_ppos = BACKUP_END + CRASH_RELOCATE_SIZE;
> read_from_oldmem(reg_buf, REG_SIZE, ®_ppos, 0);
> elf_core_copy_regs(&prstatus.pr_reg, (struct pt_regs *)reg_buf);
> buf = storenote(¬es[0], buf);
>
>
> In this place, "reg_ppos" is the pointer to the copy of relocated
> crash_smp_regs[0].
> kdump should save the "crash_smp_regs[**panic_cpu**]".
>
> Or, it is better to save all crash_smp_regs[NR_CPUS].
> In other words:
I am actually working on patches to export the registers of all
processors as elf notes sections. Similar to what multi-threaded core
dump does. This will enable gdb to correctly analyze the stack trace
on all processors.
Thanks and Regards,
Hari
next prev parent reply other threads:[~2004-11-27 6:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-18 14:08 [PATCH] kdump: Fix for boot problems on SMP Hariprasad Nellitheertha
2004-11-18 15:34 ` Badari Pulavarty
2004-11-19 17:56 ` Akinobu Mita
2004-11-19 23:30 ` Andrew Morton
2004-11-19 23:29 ` Badari Pulavarty
2004-11-20 1:05 ` Badari Pulavarty
2004-11-20 3:04 ` Akinobu Mita
2004-11-22 16:03 ` Hariprasad Nellitheertha
2004-11-22 22:34 ` Badari Pulavarty
2004-11-23 0:43 ` Badari Pulavarty
2004-11-23 18:15 ` Hariprasad Nellitheertha
2004-11-24 20:07 ` Badari Pulavarty
2004-11-25 15:13 ` Hariprasad Nellitheertha
2004-11-25 17:21 ` Akinobu Mita
2004-11-26 11:57 ` Hariprasad Nellitheertha [this message]
2004-11-20 3:46 ` Akinobu Mita
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=41A71A13.2010008@in.ibm.com \
--to=hari@in.ibm.com \
--cc=akpm@osdl.org \
--cc=amgta@yacht.ocn.ne.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=pbadari@us.ibm.com \
--cc=varap@us.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox