kexec doesn't quite work.

[XECDesign]

There are some issues with booting kernels using kexec (it doesn't work). It would be great if someone could look into it. I know there's lots of interest in being able to select kernels and rootfs without modifying files and kexec is probably the simplest, so it's definitely worth fixing, I think.

[nomis]

The power management code is probably blocking when it tries to power up the devices a second time.

diff --git a/arch/arm/mach-bcm2708/power.c b/arch/arm/mach-bcm2708/power.c
index a4139fc..7e418a1 100644
--- a/arch/arm/mach-bcm2708/power.c
+++ b/arch/arm/mach-bcm2708/power.c
@@ -163,6 +163,7 @@ static int __init bcm_power_init(void)
    int i;

    printk(KERN_INFO "bcm_power: Broadcom power driver\n");
+   bcm_mailbox_write(MBOX_CHAN_POWER, 0);

    for (i = 0; i < BCM_POWER_MAXCLIENTS; i++)
        g_state.client_request[i] = BCM_POWER_NOCLIENT;

[popcornmix]

@XECDesign
Does it boot the first time?
Do you get any console output?

[XECDesign]

@popcornmix

If by first time you mean just a standard boot, then yeah everything works just fine.

Then, without Simon's patch, when I kexec the kernel again, it says something to the effect of "Starting new kernel... bye!" and nothing happens. I haven't tried looking at the serial port output yet though. Well, I know it starts to boot, but it doesn't get very far along... not far enough to put anything on the screen.

@lp0
The patch works, thanks. However, the resolution is reset to something low, so the hdmi_mode option is ignored. Also, there are some MMC errors, but it still boots everything fine.

I'll post more info (the exact errors) once I get the serial port working.

[nomis]

"the resolution is reset to something low, so the hdmi_mode option is ignored"

Check the parameters you're passing to bcm2708_fb on the kernel command line.

[XECDesign]

After playing around with it a bit more, yeah, it definitely works great. Haven't run into any issues yet.

[popcornmix]

I've pushed lp0 suggestion.

[XECDesign]

Thanks! =)

[asb]

Reopening, as ShiftPlusOne is reporting vchiq issues after kexec (details to follow)

[XECDesign]

@popcornmix , @lp0
I've run into some trouble. Video core doesn't quite work after a kexec boot.

When launching OpenELEC and hello_triangle.bin I get the following errors:
vchiq_get_state: g_state.remote->initialised != 1 (0)
vcos: [1679]: vchiq has no connection to VideoCore

I've attached full dmesg log here.
OpenELEC:
http://pastebin.com/nS5P8A7U
ArchLinux (hello_triangle):
http://pastebin.com/Bkci4ECe

Let me know if I can provide any more information.

[Ferroin]

kexec support is still labeled as experimental on the ARM architecture in the official release, this should really be reported (and followed for updates) there. As far as I know this is one of the big areas of focus for kernel development. Although, on the Pi it really isn't that useful from what I can tell, I clocked rebooting both through kexec and normally, and get only sub-second differences in timing.

[declanmalone]

Hi, I'm wondering if something has broken in kexec since these messages here. I'm running the latest kernel and firmware (as of 3rd Dec 2012) and I can't get get kexec to work at all. I posted a detailed summary of the problem over on the RPi forums (here http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=24670&sid=bea05ce6eda0f6c50fb2c99ccbb2ab33). The quick summary of that is that kexec just gives a message about starting the new kernel, but then there's no output from the new kernel. I put in some printks to see which bits were succeeding, and it seems that we never return from machine_kexec() and that the problem lies somewhere in cpu_reset(), which is the last line executed in there.

[Ferroin]

Does kdump work? On some arches, kdump doesn't use exactly the same code as kexec, and if it works in this case it will make it much easier to figure out what is wrong with kexec.

[mkj]

Using a kernel built with earlyprintk it looks like the scheduler isn't switching to the kthreadd task for some reason. In the trace below the dd82a040 task is kthreadd and __schedule() is about to context_switch() to it. The "f" printk is at the bottom of finish_task_switch(), but a printk right at the very bottom of context_switch() doesn't appear (after return from finish_task_switch). Or perhaps that's normal - I'm not too familiar with scheduler code, and printk side-effects.

Any ideas where to look further as a culprit? My first guess would be something memory or cache related? Disabling I- and D- caches didn't help.

[    0.138046] Initializing cgroup subsys freezer
[    0.142711] Initializing cgroup subsys blkio
[    0.147415] CPU: Testing write buffer coherency: ok
[    0.152678] entering rest_init
[    0.156245] created kernel_init thread
[    0.160353] created kthreadd thread
[    0.164113] kthreadd_task dd82a040
[    0.167705] signalled kthreadd_done
[    0.171387] about to schedule() in schedule_preempt_disabled
[    0.177356] n dd82a040
[    0.179888] s
[    0.181614] .
[    0.183339] f

Nothing more printed.

From a28383cc5990e64e1ed95f484e222aa576585d7e Mon 3 June, built with RPi toolchain.

[mkj]

Kexec seems to work fine booting rpi-3.9.y , booting either from that or from the 3.6 kernel. That'll teach me for not trying the newest version first!

[popcornmix]

@mkj interesting.
Nothing's changed on our side that I can think of that would fix this. Perhaps there was some upstream fix.

[scratchy]

Hey i would like to bump this thread,

Still having trouble with a kexec't kernel:

Kernel Version:
Linux version 3.14.6+ (root@dev-vm) (gcc version 4.8.3 (Buildroot 2014.08-rc2-00028-gf67e7ba) )

dmesg after
sudo modprobe bcm2835_v4l2
http://pastebin.com/H0f4T5tJ

Modprobe is working without issues if the kernel is executed directly.
Any idears how to fix this?

Thank you :)