Bug 3525
| Summary: | Toshiba Sat Pro A10 fails to resume | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Herbert Xu (herbert) |
| Component: | Power-Sleep-Wake | Assignee: | Venkatesh Pallipadi (venki) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | dan |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.8.1 with ACPI 20040816 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: | dmesg | ||
|
Description
Herbert Xu
2004-10-08 06:23:01 UTC
Created attachment 3785 [details]
dmesg
Comment on attachment 3785 [details] dmesg ><HTML><HEAD/> ><BODY> ><H1><A href="http://bugzilla.ubuntu.com/attachment.cgi?id=368">https://bugzilla.ubuntu.com/attachment.cgi?id=368</A></H1> ></BODY></HTML> Do you have acpid running? If yes, what does /etc/acpid/* contain? I certainly do have acpid running. scutter:/home/dan# ps aux | grep acpid root 5 0.0 0.0 0 0 ? S< 23:41 0:00 [kacpid] root 3511 0.0 0.1 1500 612 ? Ss 23:41 0:00 /usr/sbin/acpid -c /etc/acpi/events -s /var/run/acpid.socket This is what I have in /etc/acpi scutter:/home/dan# ls -R /etc/acpi/ /etc/acpi/: events lid.sh powerbtn.sh power.sh /etc/acpi/events: ac battery lidbtn powerbtn Dan. Are you using power button to wake from S3. If yes Can you cat /etc/acpid/events/powerbtn My guess is, it has a shutdown in there. Comment that line (use #). That should make resume work properly. I am using the power button to resume yes, I don't see how elses I can. The
file in /etc/acpi/powerbtn.sh did have a shutdown command in it. It now has the
following.
#!/bin/sh
# /etc/acpi/powerbtn.sh
# Initiates a shutdown when the power putton has been
# pressed.
if ps -Af | grep -q '[k]desktop' && test -f /usr/bin/dcop
then
dcop --all-users ksmserver ksmserver logout 0 2 0 && exit 0
else
# /sbin/shutdown -h now "Power button pressed"
fi
You were right, if I comment out the shutdown line it works as expected. I am
using the command echo mem > /sys/power/state to go into suspend. However, I
think I should point out that this only works if the usb modules uhci_hcd and
ehci_hcd are removed from the running kernel. Otherwise it attempts to suspend
and then resumes immediately. Is this an error with the shell script then?
Also the wireless network doesn't resume correctly, it appears that I have lost
my route?
Thanks,
Dan.
It feels nice to see resume working isn't it :) You can also use lid to suspend and resume. Yes. The problem is with acpid and its configuration. But, with all the commenting, one side effect can be, you can no longer use power button to do a normal shutdown. :( USB and wireless drivers are known issues. There should be other bugzillas talking about that. There is a experimental patch for wireless driver resume (by Zhu Yi at intel). You should be able to find it through googling. Better workaround for this, rather than commenting out those lines in powerbtn.sh. Before going to sleep, do "/etc/init.d/acpid stop" and after resuming, do "/etc/init.d/acpid start". This way you will retain the functionality of the powerbtn, when you actually need it to shutdown the system. more intelligent solution : before suspending, touch a file somewhere, a "we-are-now-in-suspend-marker" if you want. On resume, check for that file (in the powerbutton handler script): it it exists, we are returning from suspend, if it doesn't exist, we are "up-and-running" and wish to shutdown. That way, you can keep using the powerbutton for these 2 purposes. FWIW, the above algoritm is what I use on my (also) Toshiba Sat Pro laptop and it works fine. HTH, David Leemans > On resume, check for that file (in the powerbutton handler script): it it > exists, we are returning from suspend, and then you delete the file of course > if it doesn't exist, we are "up-and-running" and wish to shutdown. That is a better workaround. Now that the original S3 issue is resolved, and the issue is actually with acpid daemon and not the kernel, can I close this bug saying with CODE_FIX? Any objections to this? That's fine by me. Thanks. This is a bug in acpid user daemon setup and not a bug in kernel. And there are few workarounds for the acpid daemon bug. Closing this. |