In message <1106668797.1114.1.camel@localhost>, "Jared D. McNeill" writes:
>On Tue, 2005-01-25 at 15:55 +0000, Kentaro A. Kurahone wrote:
>> On Tue, Jan 25, 2005 at 10:29:35AM -0400, Jared D. McNeill wrote:
>> [snip] 
>> > My knowledge of x86 assembler is limited, but with the following patch I
>> > am able to resume, and my machine works for about 5 seconds before all
>> > of my devices start spewing errors and key input stops working. Could
>> > someone review this patch and let me know why it seems to work (and
>> > certainly, what I'm doing that's very wrong).
>> 
>> Oh ok.  I'm guessing that's why the FreeBSD code I swiped this stuff from
>> has "hw.acpi.reset_video".   My laptop's LCD wouldn't come up unless
>> I reset it, and I left the sysctl out.
>> 
>> I've gotten this code to the point where I can reliably suspend when X11
>> is running, and the box comes up, and X11 is still running without issues.
>> 
>> Unfortunately I still need to fix pccbb and auich.  (Also see the traffic on
>> port-i386 regarding the driver/powerhooks stuff.)
>
>Mine resumes fine with my patch but my system locks hard as soon as I
>try to touch the disk ('lost interrupt' from piixide). Without my patch
>the machine freezes before ever initializing the display.
>

Ah, yes, the disk.  Disk I/O worries me about APM suspend -- sometimes 
when I resume, I see a message about a soft error on the disk.  I 
assume that that means that an I/O operation was in progress when I did 
the suspend.  I have the following in my /etc/apm/suspend:

	sync; sync
	sleep 1

because I've noticed a higher probability of crashes at resume time 
than while running.  (It may be better now that I'm not using any 
PCMCIA/CardBus cards -- the problem was correlated with presence of a 
wi0 card on my old laptop.)

More generically, I think that many -- most? -- device drivers need
suspend and resume hooks.  The former may be null for drivers where an 
interrupted operation is unimportant, such as on a network card.  But 
lots of drivers will need to reinitialize state after a resume.  Apart 
from the ones already mentioned, speedstep does the wrong thing (see 
port-i386/28790); I also have to reset the output level on my sound 
card.

		--Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb