Pavel Machek wrote:
> That probably means someone (you?) should add printk("suspend not supported by
> sonypi"); return -EINVAL; at begging of its _suspend routine, so that
> we break suspend in reliable and easy-to-debug manner?
>
Pavel Machek wrote:
> That probably means someone (you?) should add printk("suspend not supported by
> sonypi"); return -EINVAL; at begging of its _suspend routine, so that
> we break suspend in reliable and easy-to-debug manner?
>
Pavel Machek wrote:
>> Ok, after some testing i found it was the sonypi module. Now the lid
>> close is not detected, but anyway i had no use for that when i couldnt
>> suspend...
>>
>
> Be sure to report this to sonypi authors. I'd prefer not to have to
> debug it over and over and over again
Ok, after some testing i found it was the sonypi module. Now the lid
close is not detected, but anyway i had no use for that when i couldnt
suspend...
There is a replacement for this module being developped.
So,
s2ram -f -a 1
s2ram -f -a 3
and
s2ram -f -p -m
works on a
sys_vendor = "Sony
Pavel Machek wrote:
> Hi!
>
>> I can get s2ram to work from init=/bin/bash, but when I boot the full
>> OS and log in (on a text virtual terminal), the system will not
>> suspend:
>>
>> s2ram -f -a 1
>>
> Is there any difference in modules between working and broken case?
> Any interest
Hi to all.
I got to suspend to RAM from text console (with init=/bin/bash) using
$ s2ram -f -a 1
Tough, when i try the same from Gnome, it goes out to a terminal and
hangs there without shutting down (the usb mouse does power off).
Weirdly, i got it to suspend from X once with -a3, but that didn
