hangs after sleep/resume (regression)

Using the vesa driver, the resume is working, but only until I switch console
with ctrl-alt-f? or choose "switch user" at the screenlock prompt.

Is it possible to go back to Colony 5 and then figure out whether upgrading only
X breaks it?

Ok, I am doing it the hard way. I reinstalled Colony-5 and have so far upgraded
(Oct 5) all packages x* and *xorg*. Sleep/resume still works. Guess we'll have
to reassign this to another package. Now I have 275 packages left to upgrade...
Any suggestions to which to try first ? I'll try the kernel next.

BTW, acpi-support is not upgradable at this point due to dependencies on
smartdimmer and radeontool.

Oh boy - I upgraded the kernel (to -20), and it hung again at resume :( Then I
downgraded the kernel again to -14, and it still hangs. Well as my original
description would suggest, it is probably not due to the kernel version. Could
it be the kernel upgrade process or the grub reinstallation ? BTW, during
upgrade, I saw one complain about /lib/modules/2.6... not being empty.

I can have X running, switch to a text console VT, do sleep and resume. Then it
crashes in the moment I press ctrl-alt-f7.

can you try with the latest acpi-support package? (0.44)

As I said in comment 3, acpi-support won't upgrade. I tried removing the "&"
from /usr/share/acpi-support/screenblank though, and it didn't help in this case.

With regards to comments 3 and 4, I was restarting the X server
(ctrl-alt-backspace) between each bunch of upgrades that I applied. The kernel
upgrade was the first time I rebooted. There could maybe be something that took
effect after the reboot, other than the kernel ? If I would do this again, I
would reboot between the updates, but it is really a tedious process.

I have observed that the screen is not dimmed before sleep and it is not locked
at resume. It used to be, at the clean Colony 5. (Notice that I haven't upgraded
acpi-support.) Now, after the dreaded reboot, I cannot see if it's locked at
resume, it just crashes with a strange brown screen, where I vagely can see some
shadows of text - maybe like the time-stamped kernel messages.

Now I have downgraded all the packages that I had upgraded. Theoretically I
would be back to Colony-5 now. And it still hangs !

Is there a good way to verify that I really have downgraded all packages to
Colony-5 level ?

Next step would be reinstall from the cd again, and just do dpkg-reconfigure
this and that and update-grub and so on... Well, I rather gonna wait and try the
RC. If there's no other good suggestions.

does the release candidate help?

I haven't had time to install RC yet (maybe tomorrow). However, I did something
interesting (I think): I commented out the actual "echo -n $ACPI_SLEEP_MODE
>/sys/power/state" line in /etc/acpi/sleep.sh and just inserted a "sleep 5". I
could then confirm that the machine crashes, even if it has not really been
sleeping. This way it might be easier to debug and hopefully pinpoint the reason
for the crash. It has obviously not to do with the waken-up state of the machine.

Breezy RC: same problem. It crashes at the "chvt $CONSOLE;" command. Only
switching vt does no harm, I tried replacing the sleep script with a few lines
switching to vt 12 and back, and this made no crash.

Created an attachment (id=4428)
shell trace of sleep.sh

This is a log from the sleep.sh script execution, made with "exec >logfile
2>&1;set -x". The sync, sleep and echo lines are added by me for debugging
purposes. The log runs until the crash at "chvt $CONSOLE;". Unfortunately, I
can't find anything interesting in it.

The vbestate is not saved before going to sleep, but is restored during resume.
The state used is therefore the one saved during reboot in
/etc/rc2.d/S05vbesave, before X is started. The state saving part is commented
out from /etc/acpi/prepare.sh. Is this intentional ?

$ grep vbe logfile
++ VBESTATE=/var/lib/acpi-support/vbestate
++ vbetool dpms off
++ vbetool post
++ vbetool vbestate restore
++ vbetool dpms on

I gave up to track this down in Breezy. The good news is that suspend&resume is
working again in Dapper Drake Flight-2 ! I hope it will stay that way.

It works fine after a clean dapper flight 4 install, so I close this bug for now.