You are not logged in.
Pages: 1
When I press the sleep button (Fn+F1) I just get this in the message.log:
May 31 19:30:07 proton logger: EeePC 1000H: Sleep button pressed (gnome-session-suspend)
May 31 19:30:07 proton logger: execute_commands #1: /etc/acpi/eeepc/acpi-eeepc-generic-suspend2ram.sh
May 31 19:30:07 proton logger: #############################################
May 31 19:30:07 proton logger: acpi-eeepc-generic-suspend2ram.sh:
May 31 19:30:07 proton logger: Checking for processes before suspending: mplayer (1)
May 31 19:30:07 proton logger: process #0: mplayer ()
May 31 19:30:08 proton kernel: integrated sync not supported
May 31 19:30:08 proton logger: Start suspend sequence
May 31 19:30:08 proton logger: execute_commands #1: pm-suspend
I use the stock kernel, replaced the wifi card with the iwl5100 and turned KMS on. For the ACPI script, I use http://aur.archlinux.org/packages.php?ID=23318
I hope someone can help me.
Offline
Do you have mplayer running? You can add/remove different processes to the blacklist list in the configuration file /etc/conf.d/acpi-eeepc-generic.conf, near the end.
You can always try to run the suspension script /etc/acpi/eeepc/acpi-eeepc-generic-suspend2ram.sh directly from a terminal to see if it reports something wrong.
Offline
No differences:
% sudo /etc/acpi/eeepc/acpi-eeepc-generic-suspend2ram.sh
process #0: mplayer ()
execute_commands #1: pm-suspend
I think this line is the problem, but what does it mean:
Jun 1 01:52:37 proton kernel: integrated sync not supported
Offline
Ok I just checked this output means it is checking for mplayer but the "()" means it did not find it, so suspend will go on.
I remember having a similar problem. It happened when I compiled my own kernel. I probably broke something.
Are you using a custom kernel? I'm using the arch official kernel which works fine.
Which version of intel driver?
Offline
% pacman -Qi xf86-video-intel
Name : xf86-video-intel
Version : 2.7.1-1
%pacman -Qi kernel26
Name : kernel26
Version : 2.6.29.4-1
I just configured KMS:
http://wiki.archlinux.org/index.php/Int … y.27_start
Offline
Hum... This wiki should yield in the same thing as what I did...
I think the only difference between the 1000H and 1000 is the harddrive...
Something I just spotted in your output: the script is executing pm-suspend for suspension. Are you aware that this is not the default I provided for the package? The default is to simply echo mem to a file to tell the kernel to suspend. The command "pm-suspend", part of the pm-utils package, is supposed to "work better": quirks are included to cover as many machines as possible so then can all suspend correctly. The Eee should work with the vanilla suspension mechanism so you don't really need pm-utils.
Look at line 189/190 of /etc/conf.d/acpi-eeepc-generic.conf and make sure you use the echo mem:
SUSPEND2RAM_COMMANDS=("echo -n \"mem\" > /sys/power/state") # Simple suspend
#SUSPEND2RAM_COMMANDS=("pm-suspend") # Use pm-utils
Or, try to install pm-utils:
pacman -S pm-utils
Offline
SUSPEND2RAM_COMMANDS=("echo -n \"mem\" > /sys/power/state") # Simple suspend #SUSPEND2RAM_COMMANDS=("pm-suspend") # Use pm-utils
Works with that line, don't know why I changed it. The package pm-utils is installed, hal needs it.
Thanks for your quick help!
Thomas
Offline
My pleasure!
So the problem was that pm-suspend is not working... Can you run pm-suspend from the command line and see if it works?
Offline
pm-suspend works from the command line.
Offline
You need to change the following line in /etc/conf.d/acpi-eeepc-generic.conf:
Comment out:
COMMANDS_SLEEP=("/etc/acpi/eeepc/acpi-eeepc-generic-suspend2ram.sh")
And replace with:
COMMANDS_SLEEP=("/usr/sbin/pm-suspend")
Offline
Hum...
If acpi-eeepc-generic does not work I prefer fixing it then users trying some fix...
If you look at the suspending script, it is really simple. /etc/acpi/eeepc/acpi-eeepc-generic-suspend2ram.sh It checks some blacklisted processes, run "sync", saves log just in case and then execute what is present in SUSPEND2RAM_COMMANDS...
It should not do suspending twice...
Offline
Hum...
If acpi-eeepc-generic does not work I prefer fixing it then users trying some fix...
If you look at the suspending script, it is really simple. /etc/acpi/eeepc/acpi-eeepc-generic-suspend2ram.sh It checks some blacklisted processes, run "sync", saves log just in case and then execute what is present in SUSPEND2RAM_COMMANDS...It should not do suspending twice...
Thanks for taking the time to explain acpi-eeepc-generic suspend script!
If I might ask, what are the advantages of the script over using pm-suspend directly? With the right hooks, pm-suspend does a great job of shutting the right things down and starting them up again after waking up the computer.
Using the acpi script on my Asus1000he, the computer failed to go to sleep. With pm-suspend instead of the acpi script as my COMMANDS_SLEEP, everything works as expected. (But I was also just following the instructions on the Asus 1000he wiki guide.)
Is it correct that substituting pm-suspend for the acpi script in COMMANDS_SLEEP leads to a direct call to pm-suspend?
Thanks.
Last edited by madalu (2009-06-03 02:12:44)
Offline
No there is nothing wrong
I would guess using pm-suspend would be a little bit slower the directly echoing mem to /sys... But then how much and if it is really relevent...
What the script does is:
1) Verify if "/sys/power/state" contains "mem", which means the machine/kernel support suspend 2 ram.
2) Save logs
3) Sync drives
4) Run was is present in SUSPEND2RAM_COMMANDS
If you choose to run the quirks, it will first :
1.1) run xrandr to disable external moniors
1.2) Change to virtual terminal 1
See http://code.google.com/p/acpi-eeepc-gen … end2ram.sh
As you see, there is nothing much... Maybe one of these steps is breaking something. Do you have the SUSPEND_QUIRKS_VTSWITCH set to yes or no?
Offline
I had not set SUSPEND_QUIRKS_VTSWITCH.
I have a VGA monitor attached (it's listed as VGA1 by xrandr). I tried setting SUSPEND_QUIRKS_VTSWITCH first to yes and then to no and in both instances I got the message "VGA is up and running, cancelling suspend."
When I run pm-suspend, it doesn't care about the current xrandr state -- it just restores things as they are when the computer reawakens. (But I imagine there might be a problem if I disconnected the VGA while the eeepc is asleep --- is that perhaps the reason for the VGA test in the acpi script?)
By the way, thanks so much for helping to make arch run so smoothly on the Asus eeepc!
Last edited by madalu (2009-06-03 03:14:07)
Offline
About the VGA, I often use a 22 inches monitor connected to my eee. A couple of months ago when I was writing these scripts X was crashing when resumed with the monitor connected. This is why I have put the xrandr command to disable the monitor before suspending. It was not working either I think, so I have put the check to prevent suspension when the monitor was on. Maybe it works now (new X version? new intel driver? I dunno). I'll try again in the next days to see if its still necessary, maybe I could disable that.
Offline
Also, if you have problem with the package, don't hesitate to report it on the google code's issue page. I'll receive an notification email. It's also easier to follow for me then a forum post... I don't follow the forum when I'm too busy, its by luck I saw this one
http://code.google.com/p/acpi-eeepc-generic/issues/list
I want my eee to run perfectly under arch (or any other linux), and thats my way of contributing
Offline
Pages: 1