Description of problem: When trying to resume from STR there is some harddisk and cpu activity but the display is not turned on again adn the system is not responding (e.g. ctrl-alt-bkspc /del has no effect) Version-Release number of selected component (if applicable): current How reproducible: Steps to Reproduce: 1. Entering energy saving mode from gnome-panel 2. Turning on the computer again by pressing the power button 3. Actual results: Expected results: Additional info:
This happens also on HP/Compaq nx6120 laptop, suspending to disk works flawlessly tho.
SmoltID for the machine: 02c2fc00-370e-43c4-8af7-664c621d6ab0. When trying to use hibernation, X seems to be restartet, which evens out the small tie advantage of using suspend to disk...
Here too for the Samsung X20 :-( Note that this is an extremely annoying REGRESSION, resuming from suspend-to-ram worked flawlessly in FC6. As a workaround (but without taking any responsibility): installing (and booting) a FC6 Kernel (e.g. 2.6.20-1.2952.fc6 from updates) makes suspend/resume work again. In my limited testing, everything else works, too (I'm not sure what happens when using /dev/hdX in fstab versus /dev/sdX as it is correct for F7, but I have only references by label) The problem with the F7 kernel is, that e.g. the harddisk never really works after resume, only the LED goes on steady (not blinking) for some time, but without any activity, the kernel never really wakes up.
BTW, it wasn't working for me either on a Dell Latitude D410 and moving the kernel from a 586 to a 686 made it work - not sure if that explains it - just wanted to share the hint, maybe that can help diagnose the source of the issue. Sorry if this is just misleading. Worked on 2.6.21.1-3228.fc7.
Doesn't help on the samsung (I updated the i686 one again just to be sure - how do I see with rpm which arch is currently installed, by the way?). The situation will get worse, as in updates-testing there's a new libraw1394 which requires a kernel > 2.6.21-1.3194.fc7 I really hope some person with knowledge in these things can help before I can't use Fedora 7 anymore without stopping to update the system any further (as far as kernel related stuff goes).
the libraw1394 has entered updates now :-( I entered the bug in the kernel bugzilla, see http://bugzilla.kernel.org/show_bug.cgi?id=8640 for more info. If anybody from the fedora kernel maintainers could enter some information on what to do to help (testing, sending logs, whatever) I would be very very glad. I also think the bug should be changed to have a higher severity, but unfortunately this can be only done by the reporter...
Doesn't work too with presario V3320TU, kernel 2.6.21-1.3228.fc7
I tried it with the rawhide kernel (kernel-2.6.21-1.3234.fc8) and it works there :-) Is there any backport to fedora7 planned?
(In reply to comment #8) > I tried it with the rawhide kernel (kernel-2.6.21-1.3234.fc8) and it works there i tried the rawhide kernel kernel-2.6.21-1.3242.fc8 and unfortunately i cannot confirm that it works.
what do you do to suspend? I use it via the gnome-power-manager's suspend - this is different than calling pm-suspend alone... There need to be some suspend quirks added to the command to get the same effect for the X20.
OK, or better - not ok: Tried it with 2.6.21-1.3243.fc8 and it mostly is broken again. System seems to freeze right after the yellow "inu" part, with the hd light on. I manage to resume finally after some time and repeatedly clicking on the power switch (don't know if this really helps, but it seems to me...), suddenly the kernel prints out the usual debug messages as it seems to be the normal case for rawhide kernels, and brings me back to the screensaver dialog.
I try with kernel-2.6.21-1.3228.fc7 that appear at update-testing and still not work, but with kernel-2.6.22-0.5.rc7.git2.fc8 from rawhide suspend working, as a added bonus my internal mic is also working ;-)
It works for me, too with the rawhide 2.6.22 kernel. It seems there has been some restructuring in the suspend/hibernate part of the kernel for 2.6.22, so maybe it will be fixed for good then. Still no answer from any fedora guy if there is any backport planned, unfortunately. Are these bug entries read at all by redhat/fedora people?
Work for me with new kernel update, 2.6.22.1-27.fc7. Caution, if you use iwl3945 you must update iwlwifi-firmware from http://koji.fedoraproject.org/koji/buildinfo?buildID=11168 too.
Still doesn't work on the Samsung X20 for 2.6.22.1-27.fc7 :-( The recent rawhide kernels seem to continue to work. The bizarre workaround of repeatedly (and shortly to avoid poweroff) pressing the power button until it finally resumes works with the new f7 kernel (and I suppose with all the other non-working kernels, too).
Hello Jens, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage There hasn't been much activity on this bug for a while. Could you tell me if you are still having problems with the latest kernel? If it is still an issue you may like to try the following: # Find out if the system is locked up completely by hitting the caps lock key. * If the capslock light doesn't toggle, the system is completely dead. Try again, but this time before suspending, activate the pm_trace functionality with echo 1 > /sys/power/pm_trace. This reprograms the real time clock to contain a few bytes of information which we can use to diagnose which driver failed to resume. After the hang, reboot, boot up again, and save the output of dmesg. * If the capslock light does toggle, then the system did come back up, and it's possible that we just failed to reinitialise the video. http://people.freedesktop.org/~hughsient/quirk may contain further useful information to diagnose this problem. It may also be useful to initiate the suspend from a tty (ctrl-alt-f1) and run pm-suspend ; dmesg > dmesg.out ; sync by hand. Upon resuming you'll now have some more debug info to sift through. Additionally, this way when it resumes, you already have a console logged in from which you can type commands 'blind'. Trying vbetool post for example may bring things back to life. # Try rmmod'ing various modules before doing the suspend. If this makes things work again, retry with a smaller set of modules unloaded. Keep retrying until you narrow down which module is to blame. # Another trick that sometimes works to force video to come back up is to enable the BIOS password. This makes the system resume in a VGA text mode that the kernel recovers from a lot easier. Not a real solution, but it can help to diagnose other problems. If the problem has gone away then please close this bug or I'll do so in a few days if there is no additional information lodged. Cheers Chris
I'm currently using the rawhide kernel 2.6.23-0.110.rc3.git1.fc8 As described above, it will work MOST of the time. The times it doesn't work can be solved by pressing the power button some times repeatedly until the harddisk light begins to flash and the resume continues normally. I have not yet tried to check if the caps lock thing does work or not in this case, neither have I tried the most recent f7 kernel. Please note: Also for the recent f7 kernels, the workaround with pressing poweroff helped to resume. The difference was just that is was needed everytime, while the behaviour if the rawhide kernels differs erratically from version to version. Some don't work (aka: need the workaround) every time like f7, some work most of the time. I will test the current f7 kernel and - to demonstrate my willingness to cooperate :-) - I will also try what you suggest if it still doesn't work.
Created attachment 195321 [details] dmesg output after reboot
as expected, didn't work with kernel-2.6.22.5-76.fc7 --- caps lck didn't react, dmesg outut is attached.
Hi Jens, Thanks for the dmesg output. Could you attach lsmod output too. If you can also do the following, as above: Try again, but this time before suspending, activate the pm_trace functionality with # echo 1 > /sys/power/pm_trace. This reprograms the real time clock to contain a few bytes of information which we can use to diagnose which driver failed to resume. After the hang, reboot, boot up again, and save the output of dmesg. If you can do the BIOS password test as well that'd be good. Cheers Chris
well, the attached output _is_ after activating the pm_trace facility -- which i know that it worked because my clock was completely off :-) lsmod (for kernel 2.6.23-0.110.rc3.git1.fc8) says: Module Size Used by michael_mic 6465 4 arc4 5953 4 ecb 6721 4 ieee80211_crypt_tkip 13121 2 ieee80211_crypt_ccmp 9793 1 aes 31489 3 i915 24393 3 drm 69517 4 i915 hidp 21577 2 rfcomm 37993 0 l2cap 26449 10 hidp,rfcomm bluetooth 50885 5 hidp,rfcomm,l2cap ipv6 249797 30 nf_conntrack_netbios_ns 6465 0 ipt_REJECT 7617 1 nf_conntrack_ipv4 11973 11 xt_state 6081 11 nf_conntrack 53641 3 nf_conntrack_netbios_ns,nf_conntrack_ipv4,xt_state nfnetlink 8537 2 nf_conntrack_ipv4,nf_conntrack xt_tcpudp 6977 13 iptable_filter 6465 1 ip_tables 14213 1 iptable_filter x_tables 14549 4 ipt_REJECT,xt_state,xt_tcpudp,ip_tables cpufreq_ondemand 10445 1 acpi_cpufreq 12237 0 sha256 18497 0 blowfish 12353 2 cbc 7617 2 blkcipher 9285 2 ecb,cbc dm_crypt 14153 1 fuse 40165 2 sbs 20177 0 dock 12045 0 ipw2200 137001 0 snd_intel8x0m 17237 0 snd_seq_dummy 6725 0 firewire_ohci 17993 0 sdhci 18261 0 b44 26073 0 snd_intel8x0 30821 1 firewire_core 37385 1 firewire_ohci snd_ac97_codec 93821 2 snd_intel8x0m,snd_intel8x0 ssb 29013 1 b44 mmc_core 28365 1 sdhci ieee80211 31633 1 ipw2200 rtc_cmos 10977 0 ac97_bus 6337 1 snd_ac97_codec ieee80211_crypt 8513 3 ieee80211_crypt_tkip,ieee80211_crypt_ccmp,ieee80211 mii 8385 1 b44 crc_itu_t 6081 1 firewire_core snd_seq_oss 30673 0 snd_seq_midi_event 9929 1 snd_seq_oss snd_seq 46361 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event snd_seq_device 10325 3 snd_seq_dummy,snd_seq_oss,snd_seq snd_pcm_oss 38625 0 snd_mixer_oss 16969 1 snd_pcm_oss snd_pcm 65389 4 snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_pcm_oss video 19149 0 output 7105 1 video i2c_i801 12497 0 snd_timer 20957 2 snd_seq,snd_pcm battery 14161 0 ac 8133 0 i2c_core 22481 1 i2c_i801 snd 45189 13 snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer serio_raw 9285 0 iTCO_wdt 14229 0 button 10577 0 soundcore 9761 1 snd snd_page_alloc 11209 3 snd_intel8x0m,snd_intel8x0,snd_pcm iTCO_vendor_support 7109 1 iTCO_wdt sr_mod 17765 0 joydev 11649 0 cdrom 33633 1 sr_mod sg 32101 0 dm_snapshot 18365 0 dm_zero 5825 0 dm_mirror 22361 0 dm_mod 48169 15 dm_crypt,dm_snapshot,dm_zero,dm_mirror ata_piix 16069 3 ata_generic 9029 0 libata 100305 2 ata_piix,ata_generic sd_mod 27841 4 scsi_mod 122573 4 sr_mod,sg,libata,sd_mod ext3 111345 3 jbd 53921 1 ext3 mbcache 10433 1 ext3 ehci_hcd 32853 0 ohci_hcd 21837 0 uhci_hcd 24025 0 please tell me if you also need a lsmod for the f7 kernel.
lsmod from 2.6.22.5-76.fc7 [~] $ /sbin/lsmod Module Size Used by aes 31617 2 i915 27073 3 drm 80085 4 i915 hidp 26689 2 rfcomm 44377 0 l2cap 30401 10 hidp,rfcomm bluetooth 57893 5 hidp,rfcomm,l2cap ipv6 277957 28 nf_conntrack_netbios_ns 7105 0 ipt_REJECT 8641 1 nf_conntrack_ipv4 15049 11 xt_state 6593 11 nf_conntrack 63049 3 nf_conntrack_netbios_ns,nf_conntrack_ipv4,xt_state nfnetlink 9945 2 nf_conntrack_ipv4,nf_conntrack xt_tcpudp 7233 13 iptable_filter 7105 1 ip_tables 16517 1 iptable_filter x_tables 18629 4 ipt_REJECT,xt_state,xt_tcpudp,ip_tables cpufreq_ondemand 12237 1 acpi_cpufreq 14537 0 sha256 15297 0 blowfish 12609 2 cbc 8513 2 blkcipher 10437 1 cbc dm_crypt 17097 1 fuse 46293 2 video 21065 0 sbs 22729 0 button 12113 0 dock 13921 0 battery 14149 0 ac 9285 0 snd_intel8x0m 20813 0 snd_intel8x0 36061 1 snd_ac97_codec 96613 2 snd_intel8x0m,snd_intel8x0 ac97_bus 6465 1 snd_ac97_codec snd_seq_dummy 7877 0 snd_seq_oss 33473 0 snd_seq_midi_event 11073 1 snd_seq_oss snd_seq 50609 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event ipw2200 142217 0 snd_seq_device 11981 3 snd_seq_dummy,snd_seq_oss,snd_seq snd_pcm_oss 43457 0 snd_mixer_oss 19521 1 snd_pcm_oss firewire_ohci 20801 0 snd_pcm 74949 4 snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_pcm_oss ieee80211 35593 1 ipw2200 firewire_core 43137 1 firewire_ohci b44 29517 0 sdhci 20941 0 ieee80211_crypt 10049 1 ieee80211 crc_itu_t 6337 1 firewire_core snd_timer 24901 2 snd_seq,snd_pcm mii 9409 1 b44 mmc_core 30149 1 sdhci snd 53317 13 snd_intel8x0m,snd_intel8x0,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer soundcore 11681 1 snd rtc_cmos 12001 0 i2c_i801 12369 0 snd_page_alloc 13769 3 snd_intel8x0m,snd_intel8x0,snd_pcm joydev 13825 0 iTCO_wdt 14693 0 iTCO_vendor_support 7877 1 iTCO_wdt i2c_core 27841 1 i2c_i801 serio_raw 10821 0 sr_mod 20837 0 cdrom 37089 1 sr_mod sg 37469 0 dm_snapshot 20709 0 dm_zero 6209 0 dm_mirror 25153 0 dm_mod 56833 15 dm_crypt,dm_snapshot,dm_zero,dm_mirror ata_piix 18757 3 ata_generic 11589 0 libata 117809 2 ata_piix,ata_generic sd_mod 31297 4 scsi_mod 140749 4 sr_mod,sg,libata,sd_mod ext3 125513 3 jbd 59881 1 ext3 mbcache 12485 1 ext3 ehci_hcd 35405 0 ohci_hcd 23877 0 uhci_hcd 27089 0
using a bios password won't help. It will not be triggered (are you sure that this should work at all? Is the bios password requested in the case of a resume from suspend to RAM???) Anyway, for this machine the situation is still the same: no resume, only pressing some times on the power button will force the machine to continue resuming until everything works as expected. I really don't think we have a video problem here. Al the time I encountered POST problems or video cards no reinitializing, also the backlight was off. For me it is on, still the harddisk light just stays on and the machine is frozen.
(In reply to comment #23) > using a bios password won't help. It will not be triggered (are you sure that > this should work at all? Is the bios password requested in the case of a resume > from suspend to RAM???) As noted, it causes the system to resume in VGA mode which can in some instances help the kernel in the resume process - not a fix but can narrow things down. > Anyway, for this machine the situation is still the same: no resume, only > pressing some times on the power button will force the machine to continue > resuming until everything works as expected. > > I really don't think we have a video problem here. Al the time I encountered > POST problems or video cards no reinitializing, also the backlight was off. For > me it is on, still the harddisk light just stays on and the machine is frozen. I agree, I don't think its a video issue. Have you tried removing some modules before suspending - specifically I would start with your wireless card: # rmmod ipw2200 You could also try bluetooth and the sound card. Regards Chris
removed ipw2200, bluetooth (and related) and soundcore (and related) - no difference.
it works for me with recent 2.6.23 kernels and also with fedora 8 right out of the box.