That didn't work, unfortunately--apparently there wasn't a .service file providing that name to dbus.
I did, however, try with sudo /etc/acpi/sleep.sh, and I could replicate the behaviour (or at least, something that looked the same). This time, I noticed an error in the terminal about "Hardware clock contains an invalid time, cannot set system clock from it." (searching on google suggests this is not a common error, assuming I remembered it correctly). On rebooting into Windows, I found that I was in 2044. I may not have mentioned it, but last time I had a similar issue that left me in 1908. All I need now is a Delorian. I guess that the hardware clock goes wrong somewhere (whether this is a hardware problem or something in the sleep routine, I don't know), Linux rejects that as being clearly silly, but Windows accepts it and copies it to the system time (Linux then accepted 1908 after rebooting from Windows, but I set 2044 back in Windows before rebooting). I hope that the clock thing is peripheral to the thrashing issue, however. Of course, I'd forgotten that Windows IFS drivers can't mount a dirty ext3 filesystem, but happily I have a memory stick with DSL lying around. I've attached /var/log/dmesg from when I did a hard restart during the thrashing. I made a copy of the whole of /var/log/, so if you need any more information from that, please let me know. ** Attachment added: "dmesg" http://launchpadlibrarian.net/21213970/dmesg -- Huge hard drive activity after resuming from S3 suspend on a IBM x31 https://bugs.launchpad.net/bugs/15372 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
