Most recent kernel where this bug did not occur: none Distribution: Debian unstable Hardware Environment: Panasonic CF-Y5 (Intel Core Duo L2300, 82801G ICH7 chipset, Phoenix BIOS) Software Environment: up-to-date Debian unstable, 2.6.17.2 kernel (vanilla), includes modules for Intel HDA sound and 3945 wireless, but occurs without any modules loaded Problem Description: Running echo -n "mem" > /sys/power/state returns the message -su: echo: write error: Operation not permitted (ditto for attempting to write "standby" instead of "mem") Steps to reproduce:
Created attachment 8490 [details] The various outputs for ACPI: dmidecode, acpidump, and lspci -vv
Created attachment 8491 [details] output from acpidump
Created attachment 8492 [details] output from lspci -vv
Alright, simple stuff first. ls -ahl /sys/power/state? Are you running as root? cat /sys/power/state?
ls -ahl /sys/power/state? -rw-r--r-- 1 root root 4.0K Jul 5 23:10 /sys/power/state Are you running as root? yes (logged in as root, not sudo) cat /sys/power/state? standby mem (note: no "disk" state)
re: disk CONFIG_SOFTWARE_SUSPEND=y? re: permission does # echo 3 > /proc/acpi/state work any differently?
re: disk CONFIG_SOFTWARE_SUSPEND=y? No -- should I set it up? (I normally only use suspend to memory on laptops.) re: permission does # echo 3 > /proc/acpi/state work any differently? Well, there is no file /proc/acpi/state; but if I use the same idea for the file /sys/power/state, I get the following: /root# echo 3 > /sys/power/state -su: echo: write error: Invalid argument which is different from attempting to suspend: /root# echo -n "mem" > /sys/power/state -su: echo: write error: Operation not permitted So, the system is checking for valid inputs, which are presumably limited to "standby" and "mem". (I tried writing "disk" to the file, with the same error message as for trying to write "3".)
re: disk CONFIG_SOFTWARE_SUSPEND=y? One more thing: this is no longer in 2.6.17(.2), is it?
Do you have CPU hotplug enabled in the kernel? For MP, we need CPU hotplug to offline one CPU for suspend/resume.
I've observed a similar error on a UP machine with 2.6.16.9 kernel when I echoed disk into /sys/power/state. The target machine used 256M memory. When i changed the memory to 512M, everything worked OK. I used to think this is because there's little free memory space left (less than half of total memory space) and thus the exact copy when creating image will fail. But now, it seems not exact since s3 has this issue, too.
No, the 'echo disk' issue is a different one. It might be there isn't enough memory for snapshot. Bernard's issue isn't this bug.
In response to comment #9: David, Sorry to be responding so late -- I've been on nearly constant travel. I did *not* have hotplug CPU enabled. I enabled it and recompiled the kernel; with it enabled, the situation changes dramatically. First, cat /sys/power/state returns only mem whereas before the change it returned standby mem Trying to use "standby", I get this echo -n "standby" > /sys/power/state -su: echo: write error: No such device which is quite different from echo -n "disk" > /sys/power/state -su: echo: write error: Invalid argument which is also what I would get with, say echo 1 > /sys/power/state indicating that the "standby" state is considered a valid argument, but cannot be interpreted farther down the line. More importantly, this also seems to imply that I can now attempt to write to /sys/power/state So now we get to the last one: echo -n "mem" > /sys/power/state actually *works* and puts the machine in memory sleep! (For now, I have not been able to get it to wake up in any usable state, but that's probably just a question of hacking my scripts, figuring out which daemons and devices I can leave to handle themselves and which I have to handle myselves.) Thanks for the hint! I should now be able to get my machine to go to sleep properly. I remain puzzled about the change for "standby" and the continued absence of a "disk" state, but neither one is of much use to me normally, so I am not going to worry too much about it. Bernard
I'm closing this track. If you have other issues please open a new track.