为什么需要这么大的内存？vmlinux本身是没有压缩的啊
而且我试了，还是不行。
回复 11# bluempire
我之前遇到这种问题“Kernel panic - not syncing: Fatal exception”多半是内存保留不够
不过LZ的crash里面那个应该是 kdump 之外的问题
bluempire 发表于 2013-06-26 16:14 static/image/common/back.gif
为什么需要这么大的内存？vmlinux本身是没有压缩的啊
而且我试了，还是不行。
你的传上你的kernel 配置选项，以及说下你的kernel版本。另外kexec 可以不用指定dtb参数，kexec会自己去从/proc/device-tree解析。
另外crashkernel=Y@X, 你X填写为64M，试试。顺便问一下你是fsl 那个板子。
系统内核内核编译选项:(first startup kernel)
1)CONFIG_KEXEC=y
2)CONFIG_SYSFS=y
3)CONFIG_DEBUG_INFO=Y
转储内核选项(capture kernel)
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x2000000 (这个值和命令行选项“crashkernel=Y@X”中的“X” 的值相对应) CONFIG_PROC_VMCORE=y
注：这个kernel我取消掉了CONFIG_DEBUG_INFO=Y
kernel版本：2.6.31
bluempire 发表于 2013-06-27 15:41 static/image/common/back.gif
系统内核内核编译选项first startup kernel)
1)CONFIG_KEXEC=y
2)CONFIG_SYSFS=y
印象中这个CONFIG_PHYSICAL_START=0x2000000应该不是必须的，可以不具体指定地址的
lz可以试试
本帖最后由 xs3c 于 2013-06-28 10:33 编辑
回复 14# bluempire
第二个内核你不指定具体的physical_start，而把它改成肯relocated，或者你把physical_start 改成64M，再试试。我在3.4的kernel上用，没有问题。
另外，我看2.6.31的kernel只有book3S才支持kexec，BOOKE还不支持， 下面的patch才支持了booke，你确认一下.
commit b3df895aebe091b1657a42a8c859bd49fc96646b
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Sun Apr 4 22:19:03 2010 +0200
powerpc/kexec: Add support for FSL-BookE
This adds support kexec on FSL-BookE where the MMU can not be simply
switched off. The code borrows the initial MMU-setup code to create the
identical mapping mapping. The only difference to the original boot code
is the size of the mapping(s) and the executeable address.
The kexec code maps the first 2 GiB of memory in 256 MiB steps. This
should work also on e500v1 boxes.
SMP support is still not available.
(Kumar: Added minor change to build to ifdef CONFIG_PPC_STD_MMU_64 some
code that was PPC64 specific)
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
好的，我试试看。
今天定位到：Instruction TLB error了。在 MMU_init的时候。感觉跟楼上说的patch有关系。
小弟不才，敢问怎么找到这个patch，并打上？
回复 17# bluempire
从 upstream 内核里面 git show b3df895aebe091b1657a42a8c859bd49fc96646b就可以看到这个 patch 了
谢谢。这几天有事，没有调试。
我打上patch之后，开始引导crash kernel,但是启动到flash_probe，出错，请有经验的同学指点：
具体位置在：
static int __xipram cfi_probe_chip(struct map_info *map, __u32 base,
unsigned long *chip_map, struct cfi_private *cfi)
{
int i;
if ((base + 0) >= map->size) {
printk(KERN_NOTICE
"Probe at base(0x%08lx) past the end of the map(0x%08lx)\n",
(unsigned long)base, map->size -1);
return 0;
}
if ((base + 0xff) >= map->size) {
printk(KERN_NOTICE
"Probe at base(0x%08lx) past the end of the map(0x%08lx)\n",
(unsigned long)base + 0x55, map->size -1);
return 0;
}
xip_disable();
if (!cfi_qry_mode_on(base, map, cfi)) { ---------------------------此处失败了，导致do_map_probe failed.
xip_enable(base, map, cfi);
return 0;
}
谢谢了。
cfi_qry_mode_on是对flash进行探测，两天了，我暂时想不到哪里出错了？
这几天终于调试成功。
衷心感谢楼上同学的大力支持！
调试的过程，遇到了些很奇怪的问题，比如：lmb_allco导致重启，mii bus probe faied,flash probe failed等等。这些问题归根到底都是mem惹的祸。
1）也就是楼上几为同学说的参数传递的问题 mem=xxx,crash_kernel=xxx@32M,这个我调整了好几天，呵呵
2）打上xs3c/openspace兄，提醒的相关kernel patch（当然这个要看kernel版本了）
3）dtb可以不用传递。
4）initrd借用第一个kernel使用的，这部分需要修改，否则最后Mount ramdisk会失败。偷懒的办法也是有的，可以在uboot下面load到某段内存。
这样就可以读取vmcore文件了，然后再用gdb或者crash工具调试即可。
再次感谢！