From: Jay Lan <jlan@sgi.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Fastboot] Ia64 kdump patch
Date: Thu, 10 Aug 2006 19:28:42 +0000 [thread overview]
Message-ID: <44DB88EA.3010508@sgi.com> (raw)
In-Reply-To: <20060608083516.GH28607@verge.net.au>
Hi Nanhai and horms,
Zou, Nanhai wrote:
>
[snip]
> Forget to mention,
> If you are using same kernel as first and crash kernel, you'd better pass an additional
> "maxcpus=1" kernel parameter to the second kernel.
The "maxpus=1' did help. Without it, the kernel went into double panic.
However, with "maxcpus=1" i saw crash dump and Call Trace...
holism.engr.sgi.com login: SysRq : Trigger a crashdump
kernel BUG at kernel/irq/migration.c:39!
bash[3213]: bugcheck! 0 [1]
Modules linked in: radeon drm agpgart nfs
lockd sunrpc binfmt_misc dm_mirror dmi
Pid: 3213, CPU 1, comm:
bash psr :
00001010085a2010 ifs : 800000000000038b ip : [<a0000001000e1c00>]
Notdip is at move_native_irq+0x1a0/0x360
unat: 0000000000000000 pfs : 000000000000038b rsc :
0000000000000000 rnat: d6304e388f73eebc bsps:
9d40fde11cbbf11b pr : 0000000000596599 ldrs:
0000000000000000 ccv : 0000000000000000 fpsr: 0009804c8a70033f
csd : 0000000000000000 ssd : 0000000000000000
b0 : a0000001000e1c00 b6 : a000000100036060 b7 :
a000000100010150 f6 : 1003e0000006c1c8a11a7 f7 :
1003e0000000000000514 f8 :
1003e0000006c1c8a0c93 f9 : 1003e0000000000000001
f10 : 0fffd9999999996900000 f11 : 1003e0000000000000000
r1 : a000000100b66020 r2 : 000000000000048d r3 :
a0000001009665b8 r8 : 000000000000002c r9 :
0000000000003446 r10 : a00000010097d1f8 r11 :
0000000000000000 r12 : e00000001a62f7e0 r13 : e00000001a628000
r14 : 0000000000004000 r15 : a00000010097d200 r16 : 0000000000000000
r17 : 0000000000004000 r18 : 0000000000000060 r19 :
0000000000004000 r20 : a00000010097c430 r21 :
0000000000000000 r22 : a00000010096a4b8 r23 :
a00000010097d210 r24 : a00000010097d1f0 r25 : a000000100910c88
r26 : a000000100910c88 r27 : a000000100966270 r28 : 0000000000000034
r29 : 0000000000000034 r30 : 0000000000000000 r31 :
a00000010097d1cc
Call Trace:
[<a000000100013880>]
show_stack+0x40/0xa0
spà0000001a62f370 bspà0000001a6294b8
[<a0000001000144e0>] show_regs+0x840/0x880
spà0000001a62f540
bspà0000001a629460 [<a0000001000363a0>] die+0x1c0/0x2e0
spà0000001a62f540 bspà0000001a629418 [<a000000100036510>]
die_if_kernel+0x50/0x80
spà0000001a62f560 bspà0000001a6293e0
[<a000000100037c10>] ia64_bad_break+0x270/0x4a0
spà0000001a62f560
bspà0000001a6293b8 [<a00000010000c320>]
ia64_leave_kernel+0x0/0x280
spà0000001a62f610 bspà0000001a6293b8
[<a0000001000e1c00>] move_native_irq+0x1a0/0x360
spà0000001a62f7e0
bspà0000001a629360 [<a00000010004ecb0>]
iosapic_end_level_irq+0x30/0xe0
spà0000001a62f7e0 bspà0000001a629340
[<a00000010005d620>] machine_crash_shutdown+0x5c0/0x680
spà0000001a62f7e0
bspà0000001a629300 [<a0000001000d4fd0>] crash_kexec+0x70/0xc0
spà0000001a62fc60 bspà0000001a6292e0 [<a00000010045dfc0>]
sysrq_handle_crashdump+0x20/0x40
spà0000001a62fe20 bspà0000001a6292b8
[<a00000010045e1a0>] __handle_sysrq+0x160/0x300
spà0000001a62fe20
bspà0000001a629268 [<a0000001001b9770>]
write_sysrq_trigger+0xb0/0xe0
spà0000001a62fe20 bspà0000001a629238
[<a00000010012f1d0>] vfs_write+0x1b0/0x340
spà0000001a62fe20
bspà0000001a6291e0 [<a00000010012fe50>] sys_write+0x70/0xe0
spà0000001a62fe20 bspà0000001a629168 [<a00000010000c180>]
ia64_ret_from_syscall+0x0/0x20
spà0000001a62fe30 bspà0000001a629168
[<a000000000010620>] __kernel_syscall_via_break+0x0/0x20
spà0000001a630000
bspà0000001a629168
Fedora Core release 5 (Bordeaux)
Kernel 2.6.18-rc2 on an
ia64
holism.engr.sgi.com login:
However, the second kernel was not booted and system remained
alive.
The /proc/{sysrq-trigger,iomem} after the trigger were as below:
(holism,9) ls -l /proc/{sysrq-trigger,iomem}
-r--r--r-- 1 root root 0 Aug 9 08:10 /proc/iomem
--w------- 1 root root 0 Aug 9 08:10 /proc/sysrq-trigger
(holism,10)
I built the kernel based on 2.6.18-rc2 with Nanhai's
kexec-kdump-ia64-2.6.16.patch and my fixes to
- replace irq_descp(dev->irq) with irq_desc + dev->irq
- replace desc->handle with desc-chip
for compilation.
As to kexec-tools, i use kdump9 with Nanhai's
kexec-tools-kdump9-ia64-zou.patch.
What did i miss here? Do i miss any patch(es)?
My machine is a HP zx6000 loaded with FC5.
Thanks!
- jay
>
> Thanks
> Zou Nan hai
next prev parent reply other threads:[~2006-08-10 19:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-08 8:35 [Fastboot] Ia64 kdump patch Horms
2006-06-08 22:47 ` Zou Nan hai
2006-06-12 0:16 ` Zou Nan hai
2006-06-12 1:50 ` Takao Indoh
2006-06-14 23:30 ` Luck, Tony
2006-06-26 7:47 ` Horms
2006-06-26 8:10 ` Zou, Nanhai
2006-06-26 8:37 ` Horms
2006-06-26 8:49 ` Zou, Nanhai
2006-07-27 21:23 ` Zou Nan hai
2006-07-27 21:41 ` Jay Lan
2006-08-04 1:47 ` Jay Lan
2006-08-04 2:06 ` Zou, Nanhai
2006-08-04 2:08 ` Zou, Nanhai
2006-08-10 19:28 ` Jay Lan [this message]
2006-08-10 19:58 ` Jay Lan
2006-08-10 20:11 ` Jay Lan
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=44DB88EA.3010508@sgi.com \
--to=jlan@sgi.com \
--cc=linux-ia64@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox