https://bugzilla.novell.com/show_bug.cgi?id=341471#c1 --- Comment #1 from Németh Tamás 2007-11-13 13:39:52 MST --- Created an attachment (id=183241) --> (https://bugzilla.novell.com/attachment.cgi?id=183241) Suspend to disk log -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341471#c3 Pavel Machek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |seife@novell.com Status|NEW |ASSIGNED --- Comment #3 from Pavel Machek 2007-11-15 10:28:33 MST --- Is it broken only from gui, or also if you try to suspend manually using s2ram? Can you try nohz=off highres=off? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341471#c6 --- Comment #6 from Németh Tamás 2007-11-16 09:39:50 MST --- It tested is quite thoroughly. At first I tried s2ram and s2disk /dev/sda2 without giving the nohz=off and highres=off parameters to the kernel. I found that both s2ram and s2disk works under any circumstances. It doesn't matter if the notebook runs on AC or battery, the CPU frequency policy can be set to any option too, the commandline tools ALWAYS work (except one single case, when the notebook was unable to recover from STR). It also doesn't matter if I run these commands from any text based virtual terminal or from KDE's konsole under X. After testing the command line tools, I added "nohz=off highres=off" to the kernel's commandline: milleniumfalcon:~ # cat /proc/cmdline root=/dev/disk/by-id/scsi-SATA_HTS541010G9SA00_MP2ZX0XLG71D3S-part5 vga=0x317 resume=/dev/sda2 splash=silent nohz=off highres=off although: milleniumfalcon:~ # gzip -dc /proc/config.gz | grep -i -A 1 no_hz CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set And surprisingly neither the gui nor the command line tools work. When I try Suspend to Disk, the X desktop disappears (as usual), the green SuSE suspend splast screen with Z letters in the cloud appears (as usual), the progress bar decreases by 10-15%, then it stops decreasing, while the fans start to blow hot air loudly (CPU is busy) (as usual), and then the notebook remains in this stale. The progress bar freezes, fans spin as crazy and the machine is totally unresponsive. When I try Suspend to RAM with the "nohz=off highres=off" options, the system seems to suspend succesfully, but It cannot return from that state. After turning off, the display remains turned off, and the machine is totally unresponsive. Both GUI and command line tools behave this way. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341471#c7 Pavel Machek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thoenig@novell.com Status|NEEDINFO |NEW Info Provider|pavel@novell.com | --- Comment #7 from Pavel Machek 2007-11-19 03:38:06 MST --- (Please do not NEEDINFO me. I'm already the bug owner). ..ok, so seems my "nohz=off" crusade is over now :-). So command line tools work any time but graphical tools are broken on battery power...? This does not quite look like a kernel problem to me. Can you try powersave -u / powersave -U? Powersave has some debugging mode somewhere... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341471#c8 --- Comment #8 from Tamás Németh 2007-11-20 05:57:54 MST --- OK, don't panic. I will test it but I am working now. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341471#c10 --- Comment #10 from Tamás Németh 2007-11-23 17:20:16 MST --- I tested powersave as powersave -u -v 31 and powersave -U -v 31. I found it writing its logs to /var/log/pm-suspend.log. I tryed ram and disk suspend undr many circumstances, collected and renamed those log files the following way: pm-POWERSOURCE_DESTINATION_RESULTS.log Where POWERSOURCE is one of: battery: running on battery, network connection via WiFi (PRO/Wireless 3945ABG. driver module: iwl3945) AC: AC adaptor plugger, network connection via WiFi docking: Docked to docking station, AC power, network connection via Giga Ethernet (NetXtreme BMC5788, driver module: tg3) DESTINATION is either RAM or disk RESULTS indicates what happened. Sometimes a suspend attempt "bounces back" (almost succeeds but then the system continues running), sometimes it cannot be started after a virtually successful suspend, sometimes suspend/resume succeeds but some subsystems cease functioning (e.g. USB, sound, WiFi). At first I must say that I'm very disappointed because I couldn't fint the relationships between the circumstances and the results. The suspend/resume cycles produce very diverse results. When I first tryed suspend/resume cycles (just before submiting this bug report), I find that GUI suspend/resume almost always work while on AC power and never on battery power. Beside this as a consequence of "successful" S/R cycles the USB subsystem often died, which I could never reproduce sinced that day! I tryed s2ram and s2disk next. They seemed to be more stable than GUI tools, making it possible to do S/R on battery power. To tell the truth, unsuccessful resuming from RAM suspend was quite frequent. One day s2ram/s2disk did three or four consecutive unsuccessful S/R attempts while on docking station, so I thought there may be something wrong with the tg3 driver (I have no knowledge of kernel internals). But the I tried the powersave command instead of s2ram/s2disk and it worked. At first the powersave command seemed to be even more stable than s2ram/s2disk, but later I experineced the same bounces and freezes than earlier. At this point I thought that the cause can be a proprietary module loaded in my kernel. This is the cipsec module, which is part of the Cisco VPN client. My version is 4.8.01 (http://www.cisco.com/cgi-bin/tablebuild.pl/linux). So I deleted the init scripts, which load this module and tried many S/R cycles afterwards. It seemed some more stable. I was even able to do a S/R cycle initiated by GUI tools, while running on battery power. But: -s2ram/s2disk and powersave initiated S/R cycles are sill unstable. "Bounces", freezes, sound and wifi problems occur. -Today a GUI initiated S/R cycle succeeded while on battery power and the cipsec module (manually) loaded. To summarize everything above, I must say, that I couldn't find the reasons of S/R failures. In spite of this fact, I will attach two collections of powersave logfiles. One collection was created with the cipsec module loaded the other without it. However you may need some more information in addition to these logfiles. Maybe portions of dmesg when available? Daily S/R statistics? A detailed report of every failure? Or what? Any opinion? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341471#c12 --- Comment #12 from Tamás Németh 2007-11-23 17:26:39 MST --- Created an attachment (id=184596) --> (https://bugzilla.novell.com/attachment.cgi?id=184596) powersave logs generated while cisco_ipsec module was loaded -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341471#c14 Stefan Seyfried changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|nice@titanic.nyme.hu | --- Comment #14 from Stefan Seyfried 2007-11-28 03:25:08 MST --- Ok, just some information which might prove useful: - the "powersave" command and the GUI tools all do the same thing: they call a method in HAL which in turn calls "pm-suspend" or "pm-hibernate", depending if it is suspend to RAM or to disk. The only additional thing that the GUI tools are eventually doing is to tell the "media managers" of the desktop environment to unmount all external storage etc. - pm-{suspend,hibernate} do various things during suspend, logging almost all of it in /var/log/pm-suspend.log. They do unload some modules if configured, prepare the bootloader (for s2disk), do some sanity checks (especially for s2disk), eject PCMCIA cards, etc, then finally call s2ram or s2disk to do the actual suspend. - s2disk / s2ram are low level tools and sometimes the success of those is dependant on proper preparation done by pm-utils. I hope this helps a bit to understand how the process works, even if i have no real idea why it fails for you :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341471 Pavel Machek changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO Info Provider| |nice@titanic.nyme.hu -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341471 User nice@titanic.nyme.hu added comment https://bugzilla.novell.com/show_bug.cgi?id=341471#c17 --- Comment #17 from Tamás Németh 2008-01-15 04:03:57 MST --- Please wait. Processing... (It may take up to several weeks) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=341471 User nice@titanic.nyme.hu added comment https://bugzilla.novell.com/show_bug.cgi?id=341471#c19 --- Comment #19 from Tamás Németh 2008-02-18 04:20:18 MST --- Sorry, but I cannot reopen, because I couldn't find any relations between causes and effects. I've updated the kernel and suspending is still sick. -The "nohz=off highres=off" parameters still don't work. It can do a suspend, but cannot resume. -When the suspend happens while the radio kill switch turns off the WiFi transciever (or something like that), in other words when the WiFi LED doesn't light, then I have to do "/etc/init.d/network stop; modprobe -r iwl3945; modprobe iwl3945; /etc/init.d/network start" in order to be able to detect wireless networks and connect to them. -Otherwise the system often fails to do a resume from suspend, and sometimes it's even unable to go to any suspend state. I will test these suspend things on openSUSE 11.0 (maybe alpha or beta too), but I'm afraid that suspend won't work correctly on my system with 10.3. On my earlier notebook SuSE 10.1 just did every suspend perfectly. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.