Red Hat Bugzilla – Bug 241944
Resume from Suspend to Ram not working on Samsung X20
Last modified: 2007-11-30 17:12:05 EST
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):
Steps to Reproduce:
1. Entering energy saving mode from gnome-panel
2. Turning on the computer again by pressing the power button
This happens also on HP/Compaq nx6120 laptop, suspending to disk works
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 188.8.131.52-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
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, 184.108.40.206-27.fc7. Caution, if you use iwl3945
you must update iwlwifi-firmware from
Still doesn't work on the Samsung X20 for 220.127.116.11-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).
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.
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.
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-18.104.22.168-76.fc7 --- caps lck didn't react,
dmesg outut is attached.
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.
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
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
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 22.214.171.124-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
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
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.
removed ipw2200, bluetooth (and related) and soundcore (and related) - no
it works for me with recent 2.6.23 kernels and also with fedora 8 right out of