Re: In place kexec

[ebiederm@xmission.com (Eric W. Biederman)]

"H. Peter Anvin" <hpa@zytor.com> writes:

> On 07/30/2010 09:30 AM, Eric W. Biederman wrote:
>> 
>>>> That said it looks like the code to do the shutdown is in
>>>> qla2x00_remove_one so it should be too hard if someone cared to
>>>> extract just the hardware bits.
>>>
>>> Charming.  Code is there, just not hooked up.
>> 
>> Using the .remove method in reboot is a fight a lost long ago.
>> 
>
> Could you elucidate, please?

My original proposal was for device_shutdown to call the .remove
methods as those are well exercised and tested in development. aka
rmmod.

It was argued (with some merit) that for a system reboot we don't want
to perform all of the subsystem registration work, to make it more
likely that reboot -f will reboot even if there is a kernel oops.

What I proposed and unfortunately failed to write the patch for at the
time is was to have the device remove path call shutdown before calling
remove, so drivers wouldn't have to code it all up twice.

A lot of the disk drivers implement .shutdown these days and there aren't
may bug reports about kexec failing.  So I would be reluctant to change
things other than on a driver by driver basis unless I had a lot of time
for testing etc.

It might be worth playing with adding a pci_clear_master in
pci_device_shutdown.  It has the potential to break things like usb
keyboards, so I would be careful.  If it doesn't break fundamental
things like usb a pci_clear_master when shutting down devices should
improve reliability somewhat.

And of course there is the old staple of work arounds: "rmmod <driver>"
before calling kexec --exec.

Eric

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec