Description of problem: It enters in sleep mode normally. The power light start to flash slowly in orange color which indicates sleep mode. But after pressing a key so it would resume, nothing happens and the fan goes to high speed. Version-Release number of selected component (if applicable): Linux notepeter.home 2.6.41.10-3.fc15.x86_64 #1 SMP Mon Jan 23 15:46:37 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux How reproducible: Enter and exit sleep mode. It will hang the notebook. Steps to Reproduce: 1. Suspend 2. Try to resume 3. Actual results: The computer hangs Expected results: The resume should work. Additional info:
Correction: It enters in sleep mode normally. The power light start to flash slowly in orange color which indicates sleep mode. But after pressing a key so it would resume, the power light goes green and stop flashing and the fan goes to higher speed. The computer freezes.
This is still the case with the latest Fedora 16 bits, fully up to date.
I experience the same, maybe this is related with bug #790365. Since I still experience this with the latest kernel: Arch : x86_64 Version : 3.5.0 Release : 2.fc17 I will post updated info on that bug report, to see if it helps solving.
# 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).
The problem was not fixed on: Linux ace.home 3.6.2-4.fc17.x86_64 #1 SMP Wed Oct 17 02:43:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux How can I help debugging it?
The problem was not fixed on: Linux ace.home 3.6.3-1.fc17.x86_64 #1 SMP Mon Oct 22 15:32:35 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux How can I help debugging it?
Still the same bug on 3.7.7-201.fc18.x86_64 Is there anything I can do to help identifying the bug?
Is this still happening with 3.8.2 in updates-testing? If so, can you follow some of the steps here: http://fedoraproject.org/wiki/Common_kernel_problems#Suspend.2FResume_failure to see if you can narrow it down?
Still happens on 3.8.2 in updates-testing... Caps lock works for one or two seconds after resuming before hanging. echo 1 > /sys/power/pm_trace and on next boot dmesg | grep "hash matches" gave no result. I have tried: while true; do dmesg|tail -n 100 > dmesg.out;sleep 0.05;done but nothing was recorded related to suspend/resume. Am I facing SATA module problem? How can I debug it?
Linus has posted on his G+(https://plus.google.com/102150693225130002912/posts/UCoQzy8g2xB): "The suspend problems seem to be solved too. There's an annoying "feature" in the Pixel coreboot suspend code, but Duncan Laurie figured it out, and it's related to the resume code checking the TPM state. The workaround is to make sure that the TPM driver is active, which makes the coreboot TPM checks happy." How can activate TPM driver on my notebook?
I'm facing this with 3.8.2-206.fc18.x86_64 too. Like the previous comment I don't have any hash matches. I'm busy at the moment, but when I have some free time I will remove some modules trying to figure if I can find something.
Same problem on 3.8.3-101.fc17.x86_64. I have tested suspend/resume with TPM driver active and made no difference.
Using 3.8.3-101.fc17.x86_64, I have booted on text mode with additional GRUB_CMDLINE_LINUX: i915.modeset=0 vga16fb.blacklist=1 3 Then: # echo mem > /sys/power/state Nothing has changed. Same behavior.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This behaviour is still in FC19. I have this two open bugs that seems related #790365 and #917535
I've tested and the problem persists. I've disabled all network devices LAN, 3G, Wifi and Bluetooth from Bios, have disable legacy USB emulation for keyboard, have disabled AHCI mode of SATA, and the problem persists...
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
Unfortunately the bug persists with kernel 3.11.1-200.fc19.x86_64
I'll be at the Kernel Summit in Edinburgh with my notebook, and I'll be very happy to receive some pointers to fix this issue. Do you know who can I find there that could give me some help fixing this issue?
I'm trying to fix this issue, but I need your help. I'm publishing all information at: https://plus.google.com/102545580595263766229/posts/A275tmEy3Ao Can you give me any advice? Thanks!
This issue may be related to VT-d / x2apic. Disabling VT-d on the BIOS, makes the resume work. With VT-d enabled, passing nox2apic as boot parameter to Kernel also makes the resume work. I would consider both as workarounds instead of fixes...
I can confirm the #21 workarounds.
*** Bug 790365 has been marked as a duplicate of this bug. ***
*** Bug 917535 has been marked as a duplicate of this bug. ***
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.12.6-200.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those.
Bug still there with: 3.12.6-200.fc19.x86_64 #1 SMP Mon Dec 23 16:33:38 UTC 2013
Bug still there with: 3.13.5-101.fc19.x86_64 #1 SMP Tue Feb 25 21:25:32 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.13.5-100.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
Without the x2apic boot parameter I'm still unable to resume the laptop, so the bug is still present with kernel 3.13.6-200.fc20.x86_64.
This can be an firmware issue. Windows 7 do no use x2apic while Windows 8 does. There are similar bug reports for Windows 8: http://forums.toshiba.com/t5/Windows-8-8-1/Resume-from-standby-issue-on-R830-PT321A-01K002/td-p/330110 So maybe this is not a Kernel bug, and we may need to wait for a BIOS upgrade... See: https://lkml.org/lkml/2014/3/6/412
This seem to be a bug on the notebook. See comment 30.