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