[Fastboot] kexec - 2.6.14 - loads BIOS again

[Prabhakar K.]

From: Eric W. Biederman <ebiederm at xmission.com>
Subject: Re: [Fastboot] kexec - 2.6.14 - loads BIOS again
To: "Prabhakar K." <krishkar99 at yahoo.com>
Cc: "Kexec Mailing List" <kexec at lists.infradead.org>, fastboot at lists.linux-foundation.org
Date: Tuesday, September 29, 2009, 6:11 AM

"Prabhakar K." <krishkar99 at yahoo.com> writes:

>> Hi - After my previous posting I was able to make some progress.
>>
>> When I do
>>
>> kexec -l vmlinux --append="init 1 root=/dev/hda2" --console-serial
>>
>> and 
>> kexec -e,
>>
>> I get message:
>>
>> Starting new kernel
>> I'm in purgatory
>>
>> And after that it still boots from BIOS (to the same first kernel).
>>
>> Whats the problem here?
>
> I would recommend instrumenting up purgatory and then your target kernel.
>
> It is quite possible the problem is in your backport.
>
>>>>>
>  I have instrumented the purgatory code. when I run kexec -e, It hangs for a
> while at 
> sha256_starts(&ctx); in the function verify_sha256_digest(), and then reboots
> to the first kernel (from BIOS). I have put debug prints in sha256_starts, but
> none of those are executed.
>
> Interestingly, the same function sha256_starts is executed during kexec -l,
> which is called as part of update_purgatory( )( when my_load( ) is called from
> kexec.c).
> so its surprise why the same function is giving problems when kexec -e is run.

Do you by any chance have a watchdog you are not petting?
>> Yes, we do have software watchdog and hardware watchdog. I disabled software watchdog and I think the reason for resetting to the first kernel can be explained due to hardware watchdog kicking in.
To try out a different version of the kexec, I took kexec version 20080227 from http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/and instrumented that code as well. With this, I was able to see the sha 256 verification done during kexec -e and also the post verification of purgatory code. And it hangs there (does not reboot to the first kernel).
So, any conclusions based on these ? Please CC me in reply. Thanks !!

Eric


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20090928/66467db3/attachment.htm>