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