On Monday 24 April 2006 3:31 pm, Nigel Cunningham wrote: > > > > I recently observed this myself and tracked down one problem. The solution > > involves what kexec() does in much the same situation: before starting a > > new kernel, most hardware needs to be reset. Today, swsusp will suspend it > > instead, which is the root cause of the problem. > > I'm not sure that it is. If we switched to not freezing devices, we'd then > cause issues with hardware such as hard drives. They need to know that we > just want things quiesced, mainly because we don't want to spin down drives. Ignore potential performance issue for a minute -- it didn't spin anything down in my testing so far, anyway! -- and focus on correctness instead. How could it be possible to hand a device to driver with resume() and not have it in one of the two defined states for that? Either (a) powerup reset, just like during resume from STR with especially aggressive hardware; or else (b) the state suspend() left it in, ready for no-data-lossage resume()? > It seems to me that the right solution might be for these usb devices to > treat a resume from a freeze as an indication that hardware should be reset. I don't much like that model. It creates more special cases in drivers (not just USB), and redefines the "freeze" thing to be more than just "quiescede". Every special case that gets added is a breeding ground for more bugs. Also, what about the resume-from-freeze that _every_ device does during swsusp suspend? The kernel is still resuming every device, not just the ones needed to write the suspend partition. - Dave
