In place kexec

Eric W. Biederman ebiederm at xmission.com
Thu Jul 29 15:51:09 EDT 2010


Vivek Goyal <vgoyal at redhat.com> writes:

> On Thu, Jul 29, 2010 at 11:29:12AM -0700, H. Peter Anvin wrote:
>> On 07/29/2010 11:06 AM, Eric W. Biederman wrote:
>> > 
>> > Thinking about this I am a bit surprised that you would find
>> > DMA left on from a disk driver.  Historically disks have been
>> > pretty good about shutting off in this scenario.
>> > 
>> > Added to that typically we unmount all filesystems.
>> > 
>> > Calling rmmod on the driver before the final kexec --exec
>> > could be interesting, and drivers much more reliably implement
>> > .remove than .shutdown.
>> > 
>> > Network drivers are more likely to be a problem, but we should be
>> > downing all of the network interfaces before something happens.
>> > 
>> > All of which is to say kexec-in-place has generally been a lot
>> > less hassle, because it is so similar to the normal case.
>> > 
>> 
>> In particular, the supposed corruption comes from the "firmware logging"
>> feature in the qla2xxx driver.  I'd really like to understand if this is
>> a kexec problem or a qla2xxx problem.
>> 	
>
> kernel_kexec()
>    kernel_restart_prepare()
> 	device_shutdown()
>
> I would suspect it to be a qla2xxx driver problem that it did not shut
> down the device properly.

And device_shutdown calls every drivers .shutdown method.

Things like this are always a driver problem.


Eric



More information about the kexec mailing list