On Tue, Aug 26, 2014 at 04:30:08PM -0700, Mike Turquette wrote: > 2) for the kexec-kernel-case, the responsibility is on the first kernel > to set things up in a good state for the second kernel, with the > exception of using kexec to debug/examime/recover from a kernel crash, > in which case you likely don't care about this stuff as much
FWIW, we frequently use a kexec flow on Kirkwood for development here - and I have not been able to get the initial kernel to cleanly shut down before kexec'ing the second kernel. The flow we've had to use involved including a pre-kernel stub in the kexec flow that goes around and cleans up all the registers enough so that the 2nd kernel will work properly. Critically it does things like turn off ethernet DMA, because the initial kernel won't even do that :| There is some kind of support for doing this, but I ran out of time unraveling the mess of config options to actually turn it on for kirkwood.. It is tied to PM support which was/is missing elements on Kirkwood.. Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
