Bug 106897

This is apm, so yes there might be some hope. 
 
Can you try unloading usb modules before suspend and returning them after 
resume? 

Phil wrote me that USB modules are not loaded after resume, so it looks like
problem in our suspend scripts somewhere.

ok, so we need /var/log/suspend2ram.log and /var/lib/suspend2ram-state{,.resume}

Maybe just some event hook was not executed correctly.

OK. I will have that for you in just a minute. Before I forget, though, loading
the uhci_hcd module by hand after it fails to be reloaded by the APM system
appears to allow the module to survive further APM events.

Beta 3 no longer allows me to put the machine to sleep so I cannot progress this
much further for now. No error is produced in logs/console - the machine simply
ceases to respond when trying APM sleep. *sigh* If needed, I can probably
re-download beta 2, but with betas being released so quickly, I'm uncertain that
this would actually help.

ACPI produces a screen full of crash information which seems related to
savagefb, but since it isn't entered into the logs, it would need me to write it
down. I haven't done so since I believe that the ACPI implementation on this
machine may be buggy, hence my use of APM.

remove the framebuffer modules before suspend (grep fb /proc/modules and rmmod
e.g. savagefb, bug #113607) and suspend will probably work.

On the old thinkpads, both APM and ACPI should work fine (at least thats what i
experienced in the not too distant past)

The APM/usb problem with uhci-hcd exists sometimes also on IBM T40 with suse93
and suse10-beta4. 
Adding uhci-hcd to UNLOAD_MODULES_BEFORE_SUSPEND2RAM in
/etc/sysconfig/powersave/sleep normally works, but not every time. As permanent
workaround I added "modprobe -r uhci-hcd; modprobe uhci-hcd" to
/usr/lib/powersave/restore_after_suspend_to_ram

Phil, did you try #7?

No info from reporter until now. This seems to be no general problem for me.
Therefore lowering severity...

Beta 4 allows APM to work so I can now provide feedback; the problem is still
present. It makes no difference whether a USB device is plugged in
before/during/after an APM event - the uhci-hcd module is simply not reloaded.
Fresh lsmod output is about to be attached to this to demonstrate the point.

please do the following:

cd /tmp
/usr/share/doc/packages/powersave/powersave_logs

and attach /tmp/powersave_logs.tar.gz

This is not a critical bug but a normal one. Critical would mean it is making
lots of machines unusable. Since i have exactly one bug report about this and
nobody seems to be able to reproduce, i'll adjust the severity.

Created attachment 49702 [details]
powersave logs, as requested

As requested, logs for this issue.

FWIW, I'm seeing this same problem on an IBM Thinkpad A31 laptop.  uhci-hcd is 
not reloaded after apm suspend/resume.  If I load it manually, and then reload 
usbhid, etc., then things work as expected.

Jason, could you also attach powersave_logs.tar.gz as mentioned in comment #12?
I am seeing a very strange thing in Phil's logs, as /var/lib/suspend2ram-state
is empty, which i cannot really explain when reading the code and
/var/log/suspend2ram.log :-)

Phil, for debugging it would be great if you could repeat your test, but before
load "usb_storage" manually, then suspend, resume, then collect and attach the
logs. This could hint at the problem.

Created attachment 49757 [details]
powersave logs

Okay.  Here's my powersave logs.  I did notice that
/var/lib/suspend2ram-state.resume is a 0-length file....  HTH!!  And thanks!! 
=:)

thanks, we found the bug, no further logs necessary. powersaved called the
restore_after_suspend_to_ram event twice, simultaneously. This lead to
interesting race conditions, that just did not harm on my APM hardware (it is
too slow :-). This will be fixed in powersaved soon. Thanks for the reports and
logs, this was a nasty one :-)

*** Bug 116774 has been marked as a duplicate of this bug. ***

Great! Thanks, Stefan. It is (hopefully, soon, was) really annoying me. I'm glad
you managed to nail it. Any ideas if the fix will make it in for RC2?

RC2 is already done, it will probably make it into RC3 or final, if not we will
issue an YOUpdate.

If you want to test it before, you can fetch the latest and greatest package from
ftp://ftp.suse.com/pub/people/seife/powersave/SUSE-10.0-test/ (i386 and x86_64
packages)

Fix will be in RC3.

BTW: my testpackages have a small error in the postinstall script:
...
Updating etc/sysconfig/powersave/common...
Updating etc/sysconfig/powersave/disk...
/var/tmp/rpm-tmp.57054: line 739: -gt: command not found

Just ignore it, it is fixed for the final version ;-)

Just wanted to add my confirmation that your fixes solve this problem for me 
too.  Thanks VERY much, Stefan!  =:)

Created attachment 50936 [details]
powersave logs from powersave-0.10.15-5

Hm.  I am still seeing this, but I think it's caused by something going wrong
in powersave, requiring a restart (bug #116991).  The first couple of times
that I suspend/resume, the USB modules do get reloaded properly.  But as soon
as the above-mentioned bug kicks in, this stops working.  

To be precise, what happens is that at some point, when I click on "suspend to
RAM" from the kpowersave applet, I see my PCMCIA card get stopped, and all USB
devices stop working.  But that's all that happens.  I do not see the powersave
dialog come up and tell me that it's doing stuff.  So I have to do this from
the command line:

sudo /etc/init.d/powersaved restart ; sleep 5; powersave --suspend-to-ram

... which does suspend my laptop, but when I have to do this (after a started
but not completed powersave suspend to RAM), then the USB modules do not get
reloaded.  

Please let me know what else I can provide.

As mentioned in the previous attachment, I'm still having problems with this 
bug, though I'm not sure if it's a result of bug #116991.  Reopening in hopes I 
can help get this fixed.

Holger: the "Statefile disappeared" logmessage is a bug in my script logic - it
is inverted.

It looks like a suspend just hangs.
Could you do a "ps auxwwwf > /tmp/ps.out" as soon as the first suspend does not
work and attach it to this bug? I suspect that some suspend-preparation
processes are hanging somewhere.

Created attachment 50978 [details]
ps.out

Okay, here's the output of ps as requested.  This is after I've clicked
"suspend to RAM" from kpowersave.  My USB no longer works and my PCMCIA cards
have been ejected.

Created attachment 50979 [details]
powersave's logs after a failed suspend

I've just gathered these logs after I clicked "suspend to RAM" from kpowersave.
 As mentioned previously, my USB modules have all be removed, and my PCMCIA
card is deactivated.  But no dialog has come up and the laptop has not
suspended.

Created attachment 50980 [details]
/var/log/messages

Here's /var/log/messages after the failed suspend.  DEBUG is set to 15 in
powersave's common config file.  Hope this helps!

It looks like either powersaved or kpowersave is opening too many dbus
connection which are not closed afterwards. Then the number of open connection
per user is reached. If that's the case, it doesn't suprise me that powersave
doesn't work anymore. As mentioned in bug 116991, please post the output of
"rpm -qi --changelog powersave | head -n 40" to verify you are using the latest
version.

To strengthen my suspicion, can you please start the command "dbus-monitor
--system" and "dbus-monitor --session" one time as user and one time as root
after a failed suspend? One of this commands should not work.

And you are sure that this only happens when you are trying to suspend to disk?

I found a bug that causes the dbus connection not to be closed. But this only
appears when there's something wrong with the hal daemon. SO I'm not sure if the
fix really solves this problem.

seife, can you put an updated package on the ftp server when its ready?

Per comment #32:

I've done that here: https://bugzilla.novell.com/show_bug.cgi?id=116991#c9

Also, Holger, I will do that next time I see a failed suspend.

Per comment #33:

Actually, I only use suspend to RAM.  I've never had success with suspend to 
disk.  In addition, I don't see a haldaemon running on my system right now, per 
"ps waux | grep hal".  Should I start it with "/etc/init.d/haldaemon start" 
before I try to suspend the next time?

*** Bug 116991 has been marked as a duplicate of this bug. ***

Ok, I think I fixed it. Thanks a lot for reporting.

I will inform you as soon as a new package is available if you like to try.

But the hal-is-not-running-issue might be another problem. If you like, you can
file a new bugreport for this.

So... should haldaemon be running at all times?  Should I restart it if I notice 
that it's down?  Hm.  I just noticed that if I try /etc/init.d/haldaemon stop 
and start, I _still_ don't see a process actually running (ps waux | grep hal).  
Am I missing something here?

Thanks Holger!

Yes, haldaemon must is mandatory with 10.0 because many applications depend on
it. Please file another bugreport for that issue.

Okay, to answer comment #32, I just tried a suspend and it failed and this is 
what I see:

> dbus-monitor --session
Failed to open connection to session message bus: Unable to determine the 
address of the message bus

Ok, that's normal.

BTW: Are you sure you are using RC2 and not RC1?

Um.  I'm using the latest publicly-available release, which is RC1.

I just wanted to follow up on this...  RC1 is still the latest, right?  I am 
still hitting this problem at least once a day and would really like to help get 
it fixed before 10.0-final.

Yes it is. I just asked because the 'found in version' section of this bugreport
pints to RC2. To I correct this.

As mentioned in comment #36, I will provide a package and let you now.

Jason, 10.0-final is done, we're currently cleaning up and getting things out.

Let's continue working on fixing this nevertheless...

Thanks!

for anyone willing to test, i have put a package of the latest code onto
ftp://ftp.suse.com/pub/people/seife/powersave/SUSE-10.0-test/10.0-i386/powersave-0.10.15.1-0.1.i586.rpm
which should be very similar to the upcoming YOU.

released powersave update for 10.0. 

Jason, did you try with you update?

Hi Holger,

I've updated to 10.0-final and I can say that at least after two suspend/resume 
cycles, my usb modules did come back correctly.  =:)  

I still cannot figure out how to keep usbhid from being loaded at boot-time (I 
have to load lmpcm_usb instead), but my putting it in /etc/hotplug/blacklist 
doesn't help.

As far as this one, though... if you want to mark it closed/fixed, I'm okay with 
that and if I see it happen again, I can re-open it?

Thanks again Holger!!  =:)

Ok, thanks a lot for reporting/debugging. Closing the bug now.