Hi! > > > > During swsusp the system is > > > > supposed to be completely off, with no suspend power available. Hence > > > > all the power sessions are guaranteed to be interrupted, and the boot > > > > kernel doesn't have to worry about destroying any of them. > > > > > > Not necessarily. x86 hardware implementations of suspend-to-disk retain > > > some power during suspend. Not many (if any) devices will retain context, > > > but the system is definitely not completely "off". > > > > As a rule swsusp (or firmware suspend-to-disk) power off everything except > > what's needed to power up the motherboard ... or to provide "5 AM wakeup" > > type events using a battery-backed realtime clock. Maintaining VBUS power > > sessions from USB host controllers is one of those "theoretically allowed, > > but never observed in the wild" cases. Napa machine seems to maintain USB power even while turned off. > > Right, not "completely" off ... but certainly nowhere as close to "on" as > > would be true of suspend-to-RAM. And regardless, the problem in $SUBJECT > > is when Linux trashes the state which the limited "on" is there to > > maintain. > > This isn't necessarily true either. Suspend2 has supported writing the image, > then suspending to ram for a year or two. uswsusp has just gained the same > functionality. In this state, if you don't pull the plug/drain the battery, > you never actually power down. Having said that, this might be a different > kettle of fish though, because there's no boot kernel in that case. For > Suspend2 (and uswsusp, I assume), it's more akin to backing out of the cycle > at the last possible moment before powering down. Yep it is same for uswsusp, and probably irrelevant here. Pavel -- Thanks for all the (sleeping) penguins.
