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.