Hi, Thanks for your advice. >> # cat /proc/cmdline >> root=LABEL=/123 [EMAIL PROTECTED] >> # kexec -p /boot/vmlinux-2.6.16-mm1-kdump.capture --args-linux \ >> > --elf64-core-headers --initrd=/boot/initrd-2.6.16-mm1-kdump.capture.img \ >> > --append="root=LABEL=/123 init 3" > >command line looks ok. For future testings, you can also specify "irqpoll" >option to reduce the chances of driver initialization failing in second >kernel. OK. I will test with "irqpoll" option in the future.
>There was one more patch from maneesh to resolve the /proc/vmcore size >issue. On my system even if dump size was more than 4G, but /proc/vmcore >was not showing it correctly. Once I copied it to disk, size was correct. > >Can you please apply following patch also. > >http://marc.theaimsgroup.com/?l=linux-kernel&m=114322483016676&w=2 > >In fact all these patches are now in -mm2. So can directly test it with -mm2 >without applying any additional patches. Copy the dump to the disk and it >should be of right size. If it is not, can you please also provide me the >output of /proc/iomem from the first kernel. I tested kdump in 2.6.16-mm2, and the file size of vmcore is now displayed correctly. But the cp command(copy vmcore to the disk) fails. The physical address of the problem offset(4,226,876,448) is not found at map_offset_to_paddr(). Because m->offset more than this offset is not set. The content of vc_list was as follows at map_offset_to_paddr(). Debug: static u64 map_offset_to_paddr(loff_t offset, struct list_head *vc_list, struct vmcore **m_ptr) { struct vmcore *m; u64 paddr; list_for_each_entry(m, vc_list, list) { u64 start, end; start = m->offset; end = m->offset + m->size - 1; if (offset >= start && offset <= end) { paddr = m->paddr + offset - start; *m_ptr = m; return paddr; } } + list_for_each_entry(m, vc_list, list) { + start = m->offset; + end = m->offset + m->size - 1; + printk(KERN_ERR "start = %llx, end = %llx\n", start, end); + } *m_ptr = NULL; return 0; } Output: start = 190, end = 233 start = 234, end = 2d7 start = 2d8, end = 37b start = 37c, end = 41f start = 420, end = a041f start = a0420, end = fa041f start = fa0420, end = 33fa041f start = 33fa0420, end = cbf1041f start = cbf10420, end = fbf1041f(4,226,876,447) Do you have any idea why this is happening? The test environment is as follows. --------------------------------------------------------- arch : i386 smp kernel : 2.6.16-mm2 memory : 8GB kexec-tools: 1.01 + kdump7.patch + Vivek's patch(2006/03/30 "kexec -l bzImage" fails) --------------------------------------------------------- The operation log is as follows. --------------------------------------------------------- # uname -r 2.6.16-mm2-kdump.smp # free total used free shared buffers cached Mem: 8227048 132572 8094476 0 13512 57480 -/+ buffers/cache: 61580 8165468 Swap: 2096472 0 2096472 # cat /proc/cmdline root=LABEL=/123 [EMAIL PROTECTED] # kexec -p /boot/vmlinux-2.6.16-mm2-kdump.capture --args-linux \ > --elf64-core-headers --initrd=/boot/initrd-2.6.16-mm2-kdump.capture.img \ > --append="root=LABEL=/123 init 3 irqpoll" # echo c > /proc/sysrq-trigger (capture-kernel is booting.) # uname -r 2.6.16-mm2-kdump.capture # ll /proc/vmcore -r-------- 1 root root 8521843744 Mar 31 11:41 /proc/vmcore # cp /proc/vmcore dumpfile cp: reading `/proc/vmcore': Invalid argument # ll total 4131848 -r-------- 1 root root 4226876448 Mar 31 11:44 dumpfile # --------------------------------------------------------- Thanks Ken'ichi Ohmichi
_______________________________________________ fastboot mailing list [email protected] https://lists.osdl.org/mailman/listinfo/fastboot
