"H. Peter Anvin" <hpa at 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
