Pavel Machek <pavel@xxxxxxx> writes: > Hi! > >> There as been a fair amount of consensus that calling >> device_suspend(...) in the reboot path was inappropriate now, because >> the device suspend code was too immature. With this latest >> piece of evidence it seems to me that introducing device_suspend(...) >> in kernel_power_off, kernel_halt, kernel_reboot, or kernel_kexec >> can never be appropriate. > > Code is not ready now => it can never be fixed? Thats quite a strange > conclusion to make. It seems there is an fundamental incompatibility with ACPI power off. As best as I can tell the normal case of device_suspend(PMSG_SUSPEND) works reasonably well in 2.6.x. >From what I can tell there are some fairly fundamental semantic differences, on that code path. The most peculiar problem I tracked is someone had a machine that would go into power off state and then wake right back up because of the device_suspend(PMSG_SUSPEND) change. If acpi power off doesn't expect the hardware to be suspended I don't see how you can make device_suspend(PMSG_SUSPEND) a default in 2.6.x. I won't call it impossible to resolve the problems, but the people doing it must be extremely sensitive to the subtle semantic differences that exist and the burden of proof for showing things work better need to be extremely high. And the developer who reintroduces it gets to own all of the reboot/halt/power off problems in the stable tree when it gets merged. Pavel the fact that you did not articulate a possibility that your change could have caused most of the problems that were seen with it is what scares me the most. The fairly trivial and obvious problems were not addressed when the patch was merged much less the subtle ones. Your initial patch did not even touch all of the code paths necessary to achieve what it was trying to do. So yes without a darn good argument as to why it should work. I will go with the experimental evidence that it fails miserably and trivially because of semantic incompatibility and can therefore never be fixed. Eric
