Hi, Maxim Syrchin I've just found your kernel patch for mips64 SMP kexec: http://lists.infradead.org/pipermail/kexec/2008-June/001909.html I was porting your kexec part code(excluding crash_dump ) on xlr408 ,which is of 8 cores SMP mips64 . I found that in machine_kexec.c , flush_icache_range(reboot_code_buffer, reboot_code_buffer + KEXEC_CONTROL_CODE_SIZE); caused an error, so I delete this line directly,although I don't know if it would bring problem after I del it... It is strange that , in relocate_kernel.S, the operator 'REG_L s5, (s2)' caused an invalid access on kernel space. If I change REG_L to ld , everything went well. So I change all the macro such as REG_L to ld ,REG_S to sd , PTR_ADD to dadd LONG_SUB to dsub, and SZREG to 8 At the same time , I changed the kexec_smp_wait function to a simple loop, without checking the kexec_flag: .globl kexec_smp_wait kexec_smp_wait: 3: b 3b at last , the a0,a1,a3,a4 were set to address of fw_arg0, fw_arg1,fw_arg2,fw_arg3 respectively. As you see, I just let one of the cpus jumps into new kernel,while the others be in an infinite loop. After jumped into second kernel , the code seemed to be crazy. Firstly, the code seemd to stop before calling 'start_kernel---> calibrate_delay ' . However, if I added a 'printk' in any 'if branches' in 'calibrate_delay ' function , the code would stop before calling 'j start_kernel' in head.S. (This time, because printk seemed unavailable, I wrote directlly to serial address to trace the kernel). I thougt it might be the problem of irq , so I added 'disable_irq(17)' in machine_kexec before invoking reboot_code_buffer(); However, the problem was still there. I don't know why this happedn can you give me some advice on how to solve this , or if there were some mistake in my code ? Thank you regards, wilbur
