Another data point: If I restart gdm after resume from suspend2mem, gdm itself is very slow to load: It can take minutes for the login dialog to appear, then, when I log in, it can take many minutes for my session to be completely enabled (background in place, all menus and icons ready, etc.). It can be as much as several minutes even to launch a terminal window from the top menu bar.
I've seen this consistently, regardless of how I suspend (from within an active gnome session, or by stopping gdm then running /etc/acpi/sleep.sh), and regardless of whether I stop gdm before or after resuming (four different combos). The key point is starting gdm after resume. I ran top in a lower vt while starting gdm post-resume, and load average stayed consistently below 0.2; if I stop and restart gdm pre-any- suspend, load average is closer to 1.7, sometimes 2.0, until gdm has established itself. If gdm is running before the first suspend-resume cycle and I leave it running, the only thing that appears to be affected is video playback as originally described. (There is "sluggishness" in the UI, but I cannot quantify that - response just feels "off", but not enough to make office work unworkable.) Also FWIW, while testing this, I've been able to get gdm to crash on occasion* during "/etc/init.d/gdm stop" - while there is nothing in /var/crash and no core files that I can see, there is what appears to be a stacktrace in vt7. I've tried "screendump 7" to capture it, but it doesn't work (even after recreating /dev/vcs7; chvt 7 does take me to the vt, but screendump gives me no love). The trace completely fills the screen, so I am disinclined to type it in, but will if it is believed worthwhile. (*) I thought I had a consistent test case, but I'm not sure anymore: Boot, stop gdm, sleep, resume, start gdm, login, launch an application, logout, stop gdm - stacktrace.... The reason I say I'm not sure anymore is that I may have seen this at least once without the suspend-resume cycle (but only once), and I may have been able to complete the whole cycle without the trace, once or twice (last night it was consistent - this morning not so much, don't know why). For fun, I tried suspend and resume with POST_VIDEO=false, but that completely disabled X (gdm never starts, there's only the little spinning clock face on vt7). By the by, SAVE_VIDEO_PCI_STATE is irrelevant on this machine, because known of the PCI devices have the right class (0x030000) to match if condition in /etc/acpi/suspend.d/80-video-pci-state.sh), so I've not tried testing changes to that parameter. SAVE_VBE_STATE is true and the vbe restore seems to work OK. According to thinkwiki, this machine - A20m - should suspend and resume without any special care, and this has been the case since Edgy, with the exception of this X behavior. Let me know what I can do to provide more info. -- After resume, video playback is order of magnitude slower than normal https://launchpad.net/bugs/84898 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
