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. Raising two points: (1) for those who think suspend is right, you can think of it as replacing one of the extra ones with kernel_restart_prepare(); and (2) not very much code interacts with that restart prep, that's a sane audit problem. 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. - Dave
