Description of problem: When I let my laptop sleep (ACPI standby/suspend to RAM), it doesn't really wake up any more. Version-Release number of selected component (if applicable): kernel-2.6.5-1.326 How reproducible: Always Steps to Reproduce: 1. echo -n standby > /sys/power/state 2. wait for things to settle down 3. press power button to wake up Actual results: Typing this from the screen, forgive typos ;-): switches to virtual console, then: [...] Stopping tasks: ===================================================================| PM: Entering state. [...] then the power LED blinks, I wait a few seconds and press the power button. The machine halfway resumes: [...] Back to C! PM: Finishing up. PCI: Setting latency timer of device 0000:00:1d.0 to 64 PCI: Setting latency timer of device 0000:00:1d.1 to 64 PCI: Setting latency timer of device 0000:00:1d.2 to 64 [...] Then it doesn't react on anything I do until I powercycle it. Expected results: Machine resumes properly. Additional info: The aformentioned is when trying to go to standby. Will list effects on "echo -n mem > /sys/power/state" shortly. The machine is a Dell Latitude D800, with Rawhide as of today, Nvidia onboard graphic with open source nv driver. lspci and stuff follows as soon as I have rebooted it.
Created attachment 99479 [details] Output of `lspci`
Created attachment 99480 [details] Output of `lspci -v`
Please retest with kernel-2.6.5-1.358 or newer. There have been several major fixes that may have improved this situation for you. If it fails, please retest with the same version but i586 kernel.
With 2.6.6-1.391, trying to enter standby/suspend to ram results in a short sleep, then the system wakes up again, regardless of whether through /sys/power/state or /proc/acpi/sleep. Some logs: PM: Preparing system for suspend Stopping tasks: ==============================================================================================================================| PCI: Setting latency timer of device 0000:00:1d.7 to 64 PCI: Setting latency timer of device 0000:00:1f.5 to 64 tg3: eth0: Link is down. Restarting tasks... done tg3: eth0: Link is up at 100 Mbps, full duplex. tg3: eth0: Flow control is on for TX and on for RX. PM: Preparing system for suspend Stopping tasks: ==============================================================================================================================| PCI: Setting latency timer of device 0000:00:1d.7 to 64 PCI: Setting latency timer of device 0000:00:1f.5 to 64 tg3: eth0: Link is down. Restarting tasks... done tg3: eth0: Link is up at 100 Mbps, full duplex. tg3: eth0: Flow control is on for TX and on for RX. PM: Preparing system for suspend Stopping tasks: ==============================================================================================================================| PCI: Setting latency timer of device 0000:00:1d.7 to 64 PCI: Setting latency timer of device 0000:00:1f.5 to 64 tg3: eth0: Link is down. Restarting tasks... done tg3: eth0: Link is up at 100 Mbps, full duplex. tg3: eth0: Flow control is on for TX and on for RX.
can you try removing the ehci_hcd module? ANd if that doesn't work, the ochi_hcd one ?
When removing ehci_hcd and "echo -n mem > /sys/power/state", the machine suspends (at least seems to), when pressing power to bring it back, the display stays black and after a minute or so of watching a flickering HD light, I saw that it made a shutdown -p, just like if I had pressed power while it was alive. I don't have an ohci_hcd, just an uhci_hcd module shall I try it with that removed as well?
With kernel-2.6.6-1.435.2.3 and acpid-1.0.2-6 and the scripts on http://www.kananov.com/aramhome/notes/s3 which I modified a bit, I could get it to suspend and resume upon pressing Fn+ESC==Suspend. Unfortunately it doesn't always wake up (it seems it it more likely to not wake up the longer I keep it suspended) and sometimes Fn+ESC doesn't work after resuming as well.
New data points with new kernels: kernel-2.6.8-1.541 works like described above (i.e. doesn't always wake up), kernel-2.6.8-1.603 doesn't sleep because (according to the error messages) it can't put the graphics card to sleep.
any improvement with the latest errata kernel ?
No go with -1.681_FC3, but I'll have to confirm this with the open source nv driver as well (though it worked until -1.541 with the closed source one).
With the open source nv driver (not tainted), it suspends and resumes, but the resume cycle gives nasty kernel debug messages: [...] Stopping tasks: ==========================================================================| Back to C! zapping low mappings. Debug: sleeping function called from invalid context at mm/slab.c:2063 in_atomic():0[expected: 0], irqs_disabled():1 [<0211cbcb>] __might_sleep+0x7d/0x8a [<0214bf9f>] __kmalloc+0x42/0x7d [<021f48e9>] acpi_os_allocate+0xa/0xb [<0220878a>] acpi_ut_allocate+0x2e/0x52 [<02208721>] acpi_ut_initialize_buffer+0x41/0x7c [<02205474>] acpi_rs_create_byte_stream+0x23/0x3b [<02206976>] acpi_rs_set_srs_method_data+0x1b/0x9d [<0211b101>] recalc_task_prio+0x128/0x133 [<0220e15c>] acpi_pci_link_set+0xfe/0x176 [<0220e4e0>] irqrouter_resume+0x1c/0x24 [<0224366a>] sysdev_resume+0x3e/0xa5 [<02246564>] device_power_up+0x5/0xa [<0213db9a>] suspend_enter+0x25/0x2d [<0213dc08>] enter_state+0x3f/0x5e [<0213dd07>] state_store+0x83/0x91 [<0213dc84>] state_store+0x0/0x91 [<021ab44b>] subsys_attr_store+0x19/0x21 [<021ab5be>] flush_write_buffer+0x1d/0x22 [<021ab5e5>] sysfs_write_file+0x22/0x35 [<02165c82>] vfs_write+0xb6/0xe2 [<02165d4c>] sys_write+0x3c/0x62 ACPI: PCI interrupt 0000:00:1d.0[A] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device 0000:00:1d.0 to 64 ACPI: PCI interrupt 0000:00:1d.1[B] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device 0000:00:1d.1 to 64 ACPI: PCI interrupt 0000:00:1d.2[C] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device 0000:00:1d.2 to 64 ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 11 (level, low) -> IRQ 11 PCI: Setting latency timer of device 0000:00:1d.7 to 64 ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 7 (level, low) -> IRQ 7 PCI: Setting latency timer of device 0000:00:1f.5 to 64 PCI: Enabling device 0000:02:01.2 (0000 -> 0002) ACPI: PCI interrupt 0000:02:01.2[A] -> GSI 11 (level, low) -> IRQ 11 Restarting tasks... done [...] I'll try whether this has any harmful impact on the system running afterward and report back.
Hmm "works kinda", i.e. often it resumes not really, i.e. X seems to crash (backlight is on but the display is black, keyboard is dead except Alt+SysRq).
2.6.9-1.724_FC3 works mostly with the proprietary nvidia driver, i.e. X is ok but after a suspend/resume the VCs remain black (seems like no backlight). I guess this is a graphics card driver issue, if I come around to it, I'll test it with the open source nv driver as well.
Hello! I have the same problem (suspends fine but screen do not resume). I suspend by doing a 'echo -n mem > /sys/power/state' from the text console (CTRL+ALT+F1). After a failed resume I can still press the power button and shutdown correctly (even though I cannot see anything). I am running RHEL4, kernel-2.6.9-5.0.3.EL. I have attached some logs named mortengh-* - Morten Green Hermansen
Created attachment 112530 [details] mortengh "lspci"
Created attachment 112531 [details] mortengh "lspci -n"
Created attachment 112532 [details] mortengh "lspci -v"
Created attachment 112533 [details] mortengh "lsmod"
Created attachment 112536 [details] mortengh "dmesg" After the resume I made a "# dmesg > thisfile.txt" to capture the content just after the resume. I did this blindly.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
This bug has been mass-closed along with all other bugs that have been in NEEDINFO state for several months. Due to the large volume of inactive bugs in bugzilla, this is the only method we have of cleaning out stale bug reports where the reporter has disappeared. If you can reproduce this bug with current FC3 updates, please reopen this bug. If you are not the reporter, you can add a comment requesting it be reopened, and someone will get to it asap. If you are not the reporter, but can reproduce this problem against FC4, please open a new bug. Thank you.