Pavel Machek <[EMAIL PROTECTED]> writes: > > I threw it together to test a specific code path, and the fact it > > fails in software suspend is actually almost confirmation that I am on > > the right track. This actually fixed the case I was testing. > > > > In this case the failure is simply because system_state is > > not set to SYSTEM_POWER_OFF before > > kernel/power/disk.c:power_down() calls device_shutdown(). > > The appropriate reboot notifier is also not called.. > > Can you suggest patch to do it right? Or perhaps there should be > just_plain_power_machine_down() that does all neccessary > trickery?
I would call it kernel_power_down() and that is what I am suggesting is the right fix. We have it open coded in kernel/sys.c:sys_reboot() in the switch case for: LINUX_REBOOT_CMD_POWER_OFF So after the code gets factored out from there all of the cases that call machine_power_off() and pm_power_off() directly need to be updated. There are similar cases for machine_restart() and machine_halt(). But the power off case seems to be the most acute. My biggest problem with this is I get into the recursive code cleanup problem. Where I fix one piece and a bug is exposed somewhere else. And that then requires investigation and fixing. Fixing the callers of machine_power_off() is about the fifth bug fix down the chain triggered by disabling UP interrupts in device_shutdown(), SMP interrupts have always been disabled. With the first bug fix was to create system devices in the device tree.. I haven't a clue where fixing this one will lead. Recursive code fixes are a hard thing to schedule :( Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/