| Summary: | Fedora 15 & 16 on a Macbook (5.1) won't unsuspend (Fedora 14 works fine) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | yerazunis <yerazunis> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | urgent | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 16 | CC: | gansalmon, itamar, jforbes, jonathan, jskala, kernel-maint, kyle.harms, madhu.chinakonda, skywalkersymes, ted |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-11-13 15:44:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Turns out that it's not just me. See: http://www.thelinuxdaily.com/2011/06/fedora-15-lovelock-on-macbook-aluminum-guide/ for LinuxDaily's take on the same bug The problem is in the nouveau kernel module, which I determined by following the steps suggested here: http://fedoraproject.org/wiki/Common_kernel_problems#Suspend.2FResume_failure I can confirm that nouveau is causing this, since I just installed the proprietary nvidia driver, and suspend now works. How can we debug nouveau? switching to correct component ... Luke, thanks for your comments. More info: turning off accelleration in Nouveau doesn't make the problem go away (more specifically, adding "nouveau.noaccel=1" to the boot line still leaves the machine fully hung on resume from closed lid.) It is probably helpful to know the graphics card involved (from "lspci | grep VGA"): 02:00.0 VGA compatible controller: nVidia Corporation C79 [GeForce 9400M] (rev b1) Same exact result here: [wsy@ryuk ~]$ lspci | grep VGA 02:00.0 VGA compatible controller: nVidia Corporation C79 [GeForce 9400M] (rev b1) [wsy@ryuk ~]$ Another data point - turning off the entire advanced graphics mode (by setting "forced fallback mode" in the graphics setup) does _not_ fix the problem; the laptop still cannot unhibernate. Further information: After update as of 20110810 bug still exists. However I can now take video of the startup with my cellphone. I get the following error messages by dissecting the video (so there is the possibility that I'm making an error in the exact numbers). The messages appear twice, one in 80-column mode, then again smaller (in a framebuffer overlay?) but the text seems identical. - - - - - Cut here cut here cut here - - - - [ 0.199100] pci_root PMP0A00:00 address space collision: host bridge window [mem 0x000cc000-0x000cffff] conflicts with Video ROM [mem 0x000c0000-0x000ce3ff] [ 1.623732] [drm] nouveau 0000:02:00.0: Register 0x00004028 not found in PLL limits table [ 1.664082] [drm] nouveau 0000:02:00.0: Register 0x00004028 not found in PLL limits table [ 1.664141] [drm] nouveau 0000:02:00.0: Register 0x00004008 not found in PLL limits table [ 1.664246] [drm] nouveau 0000:02:00.0: Register 0x00004030 not found in PLL limits table I can confirm that this bug still exists in Fedora 16 on macbook pro 5,4. If you suspend you can never resume. Changed the header to show it's in released (and never fixed) F15 and in the freshly released Fedora 16. Is this bug being worked or is it a "won't fix"? [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. [mass update] kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository. Please retest with this update. Retested with 3.3.0 (stable). Same failure (successfully suspends to RAM, but cannot wake up). Bug not resolved. - Bill Yerazunis # Mass update to all open bugs. Kernel 3.6.2-1.fc16 has just been pushed to updates. This update is a significant rebase from the previous version. Please retest with this kernel, and let us know if your problem has been fixed. In the event that you have upgraded to a newer release and the bug you reported is still present, please change the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. If you are not the original bug reporter and you still experience this bug, please file a new report, as it is possible that you may be seeing a different problem. (Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient). With no response, we are closing this bug under the assumption that it is no longer an issue. If you still experience this bug, please feel free to reopen the bug report. |
Description of problem: Standard install of Fedora 15 released on a Macbook Unibody (product code 5.1) suspends just fine, but won't unsuspend (i.e. the 'throbber' throbs just as it should). When you open the lid, the throbber goes out (as it should) but the machine does not unsuspend. Last tested with machine having all updates as of 2011-06-16 @ 8:30 AM EDT The annoying thing is that this WORKED FINE IN F14. Version-Release number of selected component (if applicable): Fedora 15 with all updates as of 2011-06-16 exhibits the bug. Fedora 14 with all updates as of 2011-06-10 does not exhibit this bug. How reproducible: Every time. Steps to Reproduce: 1. Obtain a Macbook ("Mac Unibody", apple product code 5.1) laptop 2. Install F15 3. Close lid. 4. Open lid. 5 Notice system frozen. Only recourse is forced powerdown. Actual results: System frozen on reopening laptop lid. This happens both for "suspend in RAM" and "hibernate to disk" configurations. Expected results: Would have expected laptop to exit suspend and wake up. Fedora 14 worked fine this way. Additional info: None whatsoever. No log indications of what happened appear.