Geoff Levand wrote: > Pete/Piet Delaney wrote: > >> Geoff Levand wrote: >> | Geoff Levand wrote: >> |> Rajasekaran P wrote: >> |>> Hi Geoff, >> |>> Thanks for your information. >> |>> >> |>> I used latest kexec tools with 2.6.23 kernel built with ps3_defconfig. >> |>> This kernel boots normally on PS3. But when I add "crashkernel" >> |>> argument, it goes on hang. >> |>> >> |>> # kexec --command-line="video=ps3fb:mode:166 rhgb root=/dev/ps3da3 >> |>> crashkernel=128M at 32M" \ >> |>> --initrd=/boot/initrd-2.6.23.img \ >> |>> -l /boot/vmlinux-2.6.23 >> |>> >> |>> # taskset 1 kexec e >> |>> >> |>> Nothing happens after this. As you said earlier in your mail, I am not >> |>> getting any PRINTK outputs from kernel on screen. >> >> I was wondering about bringing in the printf() code from purgatory >> and using that to print info about what's going on in the kexec code. >> The standalone printf() might come in handy in other places; Ex: kgdb >> stub. If it was in a library it could also be used during kernel >> decompression to inform on problems occurring, like checksum errors. >> > > When the first stage kernel goes down it releases all hypervisor > resources so that whatever boots next can successful open those > resources. The frame buffer is one of those resources that are > released, and after it is, there will be no more output to the > display until the second stage image brings up its display. It > is not a matter of adding print statements or string formatting. > Oh, I thought you experienced the same problem I had with printk() calls in some of the kexec functions making it no longer work. I was considering changing my KEXEC_DEBUG() macros to using printf() instead of printk() and importing the purgatory printf() code. > -Geoff > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.infradead.org/pipermail/kexec/attachments/20080311/213c8ebf/attachment.html
