On Tue, Oct 16, 2007 at 10:29:53AM +0900, Akio Takebe wrote:
> Hi, Alex, Horms
>
> Sorry for my late responce.
> >> What do you think about it?
> >
> > The panic does seem a bit much, but shouldn't we return rather than
> >continue on with a NULL_VECTOR? Thanks,
> Yes, I also thik so.
> I'll post the new patch.
>
> I'm yet debugging kexec/kdump on HVM.
> I have a question, could you give me advice, Horms?
> kexec-tool set the new start address to jump there through
> relocate_new_kernel.
> Which function do the new start address point?
Hi Takebe-san,
After relocate_new_kernel the code should jump into purgatory. Or more
specifically, purgatory_start() which is in purgatory/arch/ia64/entry.S
in the kexec-tools source tree. Once it has finished in there it should
end up calling _start() of the second/crash kernel.
If the EFI code is not mapped at 0xf/0xc and you have not
patched kexec-tools, then the code may well get stuck in
purgatory because of the hardcoded PAGE_OFFSET which is
used in PA() inside purgatory/arch/ia64/purgatory-ia64.c
I have serveral work-arounds for this problem, so let me know
if you think that this is where you are getting stuck.
>
> 23 GLOBAL_ENTRY(relocate_new_kernel)
> 24 .prologue
> 25 alloc r31=ar.pfs,4,0,0,0
> 26 .body
> 27 .reloc_entry:
> 28 {
> [snip...
> 60 //physical mode code begin
> 61 mov b6=in1 <<<<<<<<<< this(in1) address
> 62 dep r28=0,in2,61,3 //to physical address
> [snip...]
> 177 .end_loop:
> 178 sync.i // for fc.i
> 179 ;;
> 180 srlz.i
> 181 ;;
> 182 srlz.d
> 183 ;;
> 184 br.call.sptk.many b0=b6;;
>
> BTW, xenitp is very useful.
> Thanks, Tristan.
>
> Best Regards,
>
> Akio Takebe
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home