Hi, On Monday 26 October 2009, Rafael J. Wysocki wrote: > This message has been generated automatically as a part of a report > of recent regressions. > > The following bug entry is on the current list of known regressions > from 2.6.31. Please verify if it still should be listed and let me know > (either way).
Here's a puzzle for whoever likes hardware detective work. Suspend to RAM worked just fine on the Jose's box before commit 53024df259e37ad49ee3d1f3721d4cecdd7bc357 (PM / yenta: Fix cardbus suspend/resume regression, mainline commit 0c570cdeb8fdfcb354a3e9cd81bfc6a09c19de0c) that made the resume of CardBus devices actually work. After this commit, the box hangs during resume 100% of the time. We've done quite some debugging and here's the summary of findings: 1) Resume works if pcmcia_socket_dev_resume(dev) is moved to the "regular" resume phase, after resume_device_irqs(). 2) Resume works if yenta_set_power() is not called during resume (from yenta_set_socket()). 3) It doesn't help to resume all ACPI devices before yenta. 4) It doesn't help to disable yenta events during resume (unconditionally). 5) There are two CardBus bridges in the box and according to the PM_TRACE information the _second_ one is the last device we attempt to wake up during a failing resume. Please look into http://bugzilla.kernel.org/show_bug.cgi?id=14334 for details. OK, any ideas anyone? Rafael -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
