Bugzilla – Bug 230717
ksysguard blocks resuming from s2ram -f -a 3 in suse 10.2 final, but it did not in suse 10.1 final
Last modified: 2007-06-21 20:59:06 UTC
I have been testing s2ram and suspend to disk quite thouroughly (all experiences made on acer travel mate 2413 NLM): I have tried to change /etc/pm/config s2ram parameters to many (approx. 10) of that listed on http://en.opensuse.org/S2ram With all parameters it was possible to wake the machine up properly for the first time, but none parameter functioned more than once (with some parameters, resuming occurred first after pressing win key several times), after the second suspend to ram (with that particular parameter of s2ram) resuming failed in approx 90 % (this means, that my observation is that the bug is NOT RELATED to HARDWARE, but to the SOFTWARE). With suse 10.1 final, s2ram -f -a3 worked fine (except for one minor problem not inhibiting the functionality - sometimes, screen has not been locked, sometimes some other screensaver has been selected - not the one i told KDE to use), and flawless. today, i had following experience: 1. restart the computer 2. i had five applications running, see. attachment with the desktop screenshot 3. i performed suspend to ram, /etc/pm/config with parameter S2RAM_OPTS="-f -a 3" 4. after resuming, message box telling suspend to ram failed appeared 5. approx. after 20 min of using the computer, a X Window restarted two times in a sequence (in approx. 1 s), i switched to ksysguard and noticed, that it had not been collecting the whole 20 min no data - after the restart of the x window, the data that had been collected all the 20 min scrolled to the left very quickly in the windows of the ksysguard (see the screenshot in attachment) (what would normally take 20 min, took here approx. 30 seconds). with -f -a 3, i have observed, that the network does not work after resume (under suse 10.1 final it did work) - workaround - manually switch to offline regime and then back to online (this does not work always - once, i was not able to acces the web page www.csadlb.cz (which had been loaded before the suspend to ram) via firefox, although via konqueror it WAS possible - workaround was to restart the computer - after that both browsers were able to view this page) s2ram -f -a 3 works fine under ALT CTRL F1 console under root - i tried it only approx 4 times, but i did not notice any problem. The problem lies probably in X window system (not in hardware).
Created attachment 111024 [details] resuming after suspend to ram - after approx. 20 min, x window restarted two times in a row
I should also say, that all suspend-to-ram experiments described above in "description" were performed using the start menu: CTRL + ESC, TAB, 4 times arrow-left-key, 3 times arrow-up-key, ENTER now I am checking s2ram triggered via right click on the kpowersave dock-icon - this was successful in all two experiments I performed so far..
Please don't file all your bug reports as usability problem: http://en.opensuse.org/Usability-Errors
s2ram triggered via right click on the kpowersave dock-icon seems to work like under suse 10.1 final, sometimes it is necessary to press win key several times (this was the case also under suse 10.1 final) the problem lies probably not only in the x window system, but also in the new suse start menu - suspend to ram triggered via it differs from that one triggered via kpowersave dock icon desktop screen shot in attachment - it was taken shortly after resume from suspend to ram - after resuming, i was working normally with the computer and after approx. 4 minutes, x window restarted two times in a row (like it does under suse 10.1 final before the login manager starts, if one switches during the start up to the console using ALT CTRL F1) - after this restart i switched to ksysguard and areas in the ksysguard i have marked with red rolled to the left very quicky, approx in 5 seconds, all the marked area appeared (see the desktop screenshot)
Created attachment 111045 [details] x window system restarts rather later after resuming from suspend to ram, instead of instantly after resuming
Created attachment 111047 [details] third suspend to ram after a reboot and a reboot is required To maintain clarity, all suspend to ram was performed with parameter -f -a 3 and on acer travel mate 2413 NLM notebook: after a reboot, I performed 3 times suspend to ram, triggered via dock icon of kpowersave the two first were relatively successful (but it was necessary to switch to x window by pressing the win key several times) after the third, it was not possible to access internet, so i tried rebooting and after that it was possible to access internet again this screenshot was taken approx 4 minutes after resume from the third suspend to ram
Created attachment 111048 [details] third suspend to ram after a reboot and a reboot is required again this screen shot was taken approx. 5 seconds after the previous one, in this time a spontaneous restart of x window occured (twofold restart)
Created attachment 111049 [details] third suspend to ram after a reboot and a reboot is required again network was not accessible after the third suspend to ram yes, i tried out to restart knetworkmanager, but it had no influence
Created attachment 111051 [details] third suspend to ram after a reboot and a reboot is required again network was not accessible after the third suspend to ram s2ram -f -a 3 worked under suse 10.1 final reliably!
Created attachment 111076 [details] s2ram -f -a 3 via alt ctrl F1 commandline under root makes also troubles s2ram -f -a 3 triggered via ALT CTRL F1 command line as root: after resume: if no restart of the x window system occurs, "switching from wt1 to wt1" appears in the commandline. than you can use the computer and the restart of the x window system usually occurs by 20 minutes, during using the computer (this time it happened to me when i was playing a game). after this restart, "switching back to wt1" appears in the command line. then, it is fully functional if both "switching from wt1 to wt1" and "switching back to wt1" appear in the commandline after resume, no additional restart of the x window during using the computer after resume occurs and all works fine
Created attachment 111099 [details] after resume from 5. suspend to ram triggered via ALT CTRL F1 console (s2ram -f -a 3) - before restart of the x window interesting was the window of CPU, it has definitely not been refreshing every two seconds
Created attachment 111100 [details] after resuming from 5. suspend to ram triggered via ALT CTRL F1 console (s2ram -f -a 3) - after restart of the x window patterns marked by red are typical of the period before restart of the x window (when "switching back to wt1" appears in the ALT CTRL F1 console but not "switching back to wt1" - see also comment 10)
I found a workaround, how to get the machine working after resume from suspend to ram triggered via the dock icon of kpowersave (with s2ram -f -a 3 in the etc/pm/config): how to reproduce it: 1. after suspend to ram, press power on button 2. press any key - no message box asking for password appears, only a text thawing cpus... 3. press Win key several times, until the correct x window is on 4. press any key, the type the password 5. if the restart of x window did not occur and network is not accessible or if restart of the x window occurred, but the network connection is not functional like here https://bugzilla.novell.com/attachment.cgi?id=111049&action=view, following worked so far: press ALT CTRL F1 to switch to the console and then hold the Win key pressed until cycled several times through all the terminals and x window (I let it cycle through usually three times) - then the connection to the internet is functional again (no, restart of knetworkmanager is not enough)
It actually seems to hang somewhere in s2ram for quite some time. If you do not press the Win key but wait for some time, does it eventually resume back to X? Can you attach /var/log/pm-suspend.log after a resume? Maybe we can see something in there.
(In reply to comment #14) > It actually seems to hang somewhere in s2ram for quite some time. > If you do not press the Win key but wait for some time, does it eventually > resume back to X? > > Can you attach /var/log/pm-suspend.log after a resume? Maybe we can see > something in there. > below I attach the the file I noticed following (I use suspend to ram very often): 1. it seems to me, that ksysguard inhibits somehow the restart of x - if i start suspend to ram via start menu (CTRL + ESC, TAB, 4 times arrow-left-key, 3 times arrow-up-key, ENTER) and ksysguard is running, it is very probable, that the restart of x does not occur after resume if ksysguard is not running, and suspend to ram is triggered the same way, i was able to repeat this up to approx. 7 times without problem, even the restart of x occurs spontaneously and almost immediately after resuming triggering the suspend to ram via start menu (as described above - via keyboard) sooner or later ended the way that network was inaccessible (as documented in comment 16) - what helps, is to start yast/network devices/network card - click next, edit, next and finish - then network is accessible again if the suspend to ram is triggered via start menu and ksysguard is not running, then restart occurs spontaneously usually almost immediately after resume, but the user is not asked for password, although it should do so 2. if suspend to ram is triggered via dock icon of kpowersave, and ksysguard is not running, everything works fine and user is asked for password except one detail - one has to press the win key three times until switched to the correct x window
Created attachment 112106 [details] suspend to ram triggered via start menu using keyboard as described above, after the last resume, it was neccessary to restart network as described above (it was not accessible, documented below)
Created attachment 112107 [details] restart of the network needed, as described in comment 14 not comment 14 but comment 15
What network driver are you using? You probably need to file bugreport against that... 8139too? What is the other problem...? It suspends, then resumes, but s2ram fails to exit for 20 minutes?
(In reply to comment #18) > What network driver are you using? You probably need to file bugreport against > that... 8139too? > I do not know, what network driver is, but i use LAN network sorry, what is 8139too? i am a windows like user > What is the other problem...? It suspends, then resumes, but s2ram fails to > exit for 20 minutes? sorry, I didnt catch anything...
(In reply to comment #14) > It actually seems to hang somewhere in s2ram for quite some time. > If you do not press the Win key but wait for some time, does it eventually > resume back to X? yes, it resumes after some time (=restart of x), usally after 5 minutes, but I experienced even logner periods, like 10 min or even 20 - this is documented in comment 1 with one screenshot during that period before restart of x, suse is not fully functional - e.g. killing of processes using ksysguard works not and network is not accessible
hm, strange. The log of comment #16 does not show anything unusual. The network problem is probably a problem of network manager or of your network driver (whose name is 8139too), but you could solve or work around this by creating a hook to restart the network, as described in http://en.opensuse.org/Pm-utils. This could also explain why it worked in 10.1: the infrastructure was different there. It would be helpful if you could post the pm-suspend.log after a resume that did not work well.
Created attachment 112914 [details] one suspend, that failed here is one suspend to ram, that "failed" - it was triggered via the start menu - on resume, a text file that was under cursor in krusader on suspending to ram was loaded approx 120 times (see the next attachment) (krusader was the application directly behind the start menu on suspending the computer to ram) when i was killing the approx. 120 times launched text file (with application Kwrite) using ksysguard, a spontaneous logoff occured - after logging in, all was ok and computer worked properly in the next next comment, there is the var/log/pm-suspend.log It seems to me, that the main problem is ksysguard - now when I want my machine suspend to ram, i always close ksysguard before that, and this really helps! With this workaround (closing ksysguard before suspend to ram), resume after suspend to ram is possible: 1. if triggered via kpowersave dock icon, restart of x does not occur by itself, you have to pres win key and hold it for approx 5 sec (only password protection is ignored, although explicitly required by the user - in kpowersave settings/general settings/lock screen) 2. if triggered via start menu, pressing the win key several times to switch to x window is often necessary (and in this case password protection is ignored, although explicitly required by the user - in kpowersave settings/general settings/lock screen), sometimes x window is started automatically and then password is required
Created attachment 112915 [details] a text file loaded approx 120 times after resuming from suspend to ram for detailed description, see previous comment
Created attachment 112916 [details] one suspend, that failed - the log file for description, see comment 22
That logfile looks perfectly good. Note that the "suspend failed" popup is an error in kpowersave / the start menu / DBus. The suspend does not really fail, it is just signalled that it fails. The screen not being locked after suspending from the start menu is a KDE bug, not a suspend bug. What i meant was "the logfile after a suspend that did not switch back to X without interaction (hitting the win key or simply alt-f7". Just ignore that "suspend failed" popup until a fixed kpowersave package is available.
Okay, I'm not sure what is going on here. If it works okay without ksysguard, just stop using ksysguard... Sorry, we do not see the problem here.
(In reply to comment #27) > Okay, I'm not sure what is going on here. If it works okay without ksysguard, > just stop using ksysguard... Sorry, we do not see the problem here. > is this a joke?
No, it is not a joke. Problem does not seem to be reproducible here (so we can't fix it), and "not using ksysguard" seems like perfectly sane solution to me. Can you post lsmod? Are all the modules you use marked as supported? (Stefan, if ksysguard uses lm_sensors or something... it is well possible that hell breaks loose).
(In reply to comment #31) > No, it is not a joke. > > Problem does not seem to be reproducible here (so we can't fix it), and "not > using ksysguard" seems like perfectly sane solution to me. but it works perfectly resume after the first suspend to ram after a reboot works, I observe the problem usually at the second or third time. > Can you post lsmod? here is the output of lsmod Module Size Used by button 10896 0 sg 38044 0 sd_mod 24576 0 usb_storage 82112 0 scsi_mod 136712 3 sg,sd_mod,usb_storage i915 23040 4 drm 71316 5 i915 af_packet 29320 2 ipv6 263584 14 snd_pcm_oss 53376 0 snd_mixer_oss 21248 1 snd_pcm_oss snd_seq 60272 0 snd_seq_device 12812 1 snd_seq battery 14340 0 ac 9476 0 apparmor 55572 0 aamatch_pcre 18304 1 apparmor nls_iso8859_1 8320 1 nls_cp437 9984 1 vfat 16640 1 fat 55324 1 vfat nls_utf8 6272 1 ntfs 210580 1 loop 20488 0 dm_mod 60184 0 pcmcia 40892 0 firmware_class 14080 1 pcmcia ide_cd 42272 0 cdrom 38432 1 ide_cd 8139too 30592 0 yenta_socket 30348 1 mii 9600 1 8139too rsrc_nonstatic 17024 1 yenta_socket i2c_i801 11660 0 ehci_hcd 34696 0 pcmcia_core 43412 3 pcmcia,yenta_socket,rsrc_nonstatic intel_agp 27804 1 i2c_core 25216 1 i2c_i801 uhci_hcd 26892 0 agpgart 35528 3 drm,intel_agp usbcore 114896 3 usb_storage,ehci_hcd,uhci_hcd snd_intel8x0 36764 1 snd_ac97_codec 95648 1 snd_intel8x0 snd_ac97_bus 6400 1 snd_ac97_codec snd_pcm 86916 3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec snd_timer 27908 2 snd_seq,snd_pcm snd 61188 10 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_devic e,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer soundcore 13792 1 snd snd_page_alloc 14472 2 snd_intel8x0,snd_pcm ext3 141192 2 mbcache 12804 1 ext3 jbd 70324 1 ext3 edd 13892 0 fan 8964 0 thermal 18568 0 processor 34664 1 thermal piix 13700 0 [permanent] ide_disk 20480 6 ide_core 129992 4 usb_storage,ide_cd,piix,ide_disk > Are all the modules you use marked as supported? This is a too short question for me, sorry, I am a USER.
i'd guess that this is fixed with the various improvements that have gone into the kernel for 10.3, at least i cannot reproduce this here. I'll close this as WORKSFORME in 10.3 alpha5, if it doesn't work for you, please reopen.