I believe I have traced the bug. Anyway, in my suspend/resume testing, through trial and error I found that the issue does NOT occur if I unload the ohci1394 module prior to suspend. Even if I'm having it occur almost every suspend on a particular boot, unloading ohci1394 makes it go away. As this was unnecessary for the -12 kernel, I am suspicious that a commit relating to ohci1394 between the -12 and -13 kernel is our problem.
As of now, the only one I see is: * ieee1394: ohci1394: fix initialization if built non-modular Can the devs look into this? As of now, I would venture to guess that this issue happens on Intel-chipset laptops with Firewire chipsets making use of the "ohci1394" module. ** Summary changed: - New in 2.6.22-13: System doesn't always wake from suspend + New in 2.6.22-13: ohci1394 causes system to take a LONG time to resume from suspend ** Description changed: Binary package hint: linux-image-2.6.22-13-generic On my MacBook Core Duo (first generation, 32-bit), in the newest Ubuntu kernel I have no video after resuming from suspend-to-RAM on my MacBook - about 1 out of every 4 or 5 suspend/resume cycles. This only started - after the recent update to the kernel - things worked fine in Gutsy up - until that time. This occurs whether I use X.org's "intel" or "i810" - video drivers and seemed to begin happening around the time of the - kernel update - hence my belief that it is somehow kernel-related. + for a *long* time (like 5-10 minutes) about 1 out of every 4 or 5 + suspend/resume cycles. This only started after the recent update to the + kernel - things worked fine in Gutsy up until that time. This occurs + whether I use X.org's "intel" or "i810" video drivers and seemed to + begin happening around the time of the kernel update - hence my belief + that it is somehow kernel-related. + + NOTE: I have since traced this issue to the "ohci1394" module - + evidently an update between -12 and -13 makes it not play nice with + suspend. I have attached the following logs from /var/log - dmesg acpid kern.log user.log Please note that the "suspend failed" in the user.log is erroneous - in that case, suspend actually succeeded but gnome-power-manager is known to be erroneously reporting failure (bug 137738 - there is a patch in that bug but it hasn't been applied). -- New in 2.6.22-13: ohci1394 causes system to take a LONG time to resume from suspend https://bugs.launchpad.net/bugs/151016 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
