Thanks for that Steve, it helps narrow down the options quite a bit. The good news is the problem can be reproduced using the scripts so it isn't just a Gnome issue - this makes it easier to debug.
Secondly, The log shows the PC is told to turn off but refuses so that takes us into the realms of the ACPI Suspend code that I've become quite friendly with recently, chasing down a very weird suspend-the-resume- immediately issue. To get to the bottom of this we may need to run one of my custom-patched ACPI debug kernels that prints to the kernel-log right up to the last ASM instruction before the hardware is put to sleep. I've found it invaluable at working out where the issues lie quickly and efficiently. However, before that, I'd like to try out a new technique I've developed if you'd agree to be the guinea-pig. I've just started using SystemTap modules (http://sourceware.org/systemtap/) to non-invasively log what a standard-build kernel is doing. With your permission I'd like to create a SystemTap module for your 32-bit tribe 5 ( 2.6.22-10-generic ?) install that you can run to capture more information on where the kernel is getting to. It might need a few iterations of the module-script to get it peeking into the correct places. -- suspend works on tribe 5, fails with updates since then, vaio TZ190N https://bugs.launchpad.net/bugs/136688 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
