On Tuesday 25 April 2006 6:16 pm, Nigel Cunningham wrote: > Hi. > > On Wednesday 26 April 2006 09:55, David Brownell wrote: > > On Tuesday 25 April 2006 3:18 pm, Nigel Cunningham wrote: > > > I saw the 2 suspends, 1 resume comment in another part of the thread, but > > > don't believe a driver would be able to detect that 2 suspends and 1 > > > resume call had been made - at least not without some non volatile ram. > > > > The extra suspend is just IMO a symptom of sloppiness, like a "here may be > > bugs" sign. Not necessarily an issue in its own right. > > > > In fact if you count carefully, it's three suspends and one resume: one > > suspend before calling swsusp_resume, one inside swsusp_resume -- replaced > > by my patch -- and a correctly matched pair in the kernel being resumed. > > That doesn't sound right. Let' see - where's this third one? I see your point ... device_suspend() and device_power_down() really do the same thing, but to different sets of devices. A nastily deceptive naming convention that I may want to fix someday. So it's not quite fair counting those separately. Three suspend calls, sure ... but only two per device. > > Also, about non-volatile RAM. Not necessary ... the device hardware holds > > all the relevant state. The problem is that swsusp is now trashing it with > > those suspend calls before resuming the real kernel. On the plus side, we > > already have code being used to resolve the identical issue for kexec(), > > and all my patch does is to use it. > > If devices really do get powered down, then they won't retain the state. If > they don't actually powerdown, then I see your point. While the system is restarting into the snapshot, there's no powerdown. (Because device_power_down doesn't actually power down devices.) Q.E.D. - Dave
