On Wednesday 26 April 2006 6:22 pm, Patrick Mochel wrote: > On Mon, Apr 24, 2006 at 02:29:51PM -0700, David Brownell 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 is a good thing to do for a lot of video chipsets on x86 > platforms. For many, we do not have a way to reinitialize them from scratch, > so if we do a reset on them then we shoot ourselves in the foot. I was waiting for someone else to bring up video; it wasn't exactly the elephant-in-the-room-that-nobody-wants-to-talk-about, but it was clearly a trouble spot missing from the discussion. Agreed that it'd be good not to reset video hardware. Of the handful of drivers that try to do anything specific with FREEZE, Mr. Grep reports that we have USB, IDE ... and a bunch of video drivers. > It's very difficult to know what every single device needs, so we should just > be honest with the drivers - tell them exactly what we're about to do - and > let them handle it as appropriate.. There does seem to be agreement that the current FREEE invocation is not sufficient. I'm looking at a slightly different solution now ... one which unfortunately involves changing drivers, but can indeed allow swsusp resume paths to do the right thing (instead of what it does now). - Dave
