PATCH: Resume from suspend issue seems to be generally solved!!!!
Christopher Hrabia
Best regards
Chih-Wei Huang
> Hello everybody,
> after many hours of reading through the android code, trying some changes
> and reading system documentation in the www... it seems like I found the
> problem and solution for the resume from suspend issue in Android-x86 for
> all branches (maybe also interesting for other ports).
>
> The problem was that we restart surfaceflinger after resuming from suspend
> although we do not start surfaceflinger on regular boot (see below). I don't
> know why we are not using surfaceflinger.
>
> #service surfaceflinger /system/bin/surfaceflinger
> # class main
> # user system
> # group graphics
> # onrestart restart zygote
Surfaceflinger as a standalone daemon is introduced
since honeycomb. Before that surfaceflinger is just
a service forked by system_server.
If we set the property system_init.startsurfaceflinger=1
honeycomb will keep the old behavior.
I don't remember why I chose to keep old behavior in
honeycomb-x86, probably because it's easier to debug.
However, in ics-x86 we run surfaceflinger as
a standalone daemon, like an android phone.
> What is still a bit strange with resume and suspend is that on suspending my
> device it wakes up immediately one time and goes to permanent suspend
> afterwards.
>
> THE PROBLEM IS ONE LINE OF CONFIGURATION!!!!!
>
> diff --git a/target/board/generic_x86/init.rc
> b/target/board/generic_x86/init.rc
> index a91ebd3..83283ed 100644
> --- a/target/board/generic_x86/init.rc
> +++ b/target/board/generic_x86/init.rc
> @@ -422,7 +422,7 @@ service zygote /system/bin/app_process -Xzygote
> /system/bin
> socket zygote stream 666
> onrestart write /sys/android_power/request_state wake
> onrestart write /sys/power/state on
> - onrestart restart surfaceflinger
> +# onrestart restart surfaceflinger
> onrestart restart media
> onrestart restart netd
I don't think it's the culprit of suspend/resume issue.
Actually on resume zygote is not restarted.
However, it's reasonable to remove that line,
as explained above.
> Another thing attracted my attention in this file:
>
> chown radio system /sys/android_power/state
> chown radio system /sys/android_power/request_state
> chown radio system /sys/android_power/acquire_full_wake_lock
> chown radio system /sys/android_power/acquire_partial_wake_lock
> chown radio system /sys/android_power/release_wake_lock
>
> onrestart write /sys/android_power/request_state wake
>
> We do not have the android_power driver integrated in our kernel (maybe also
> some other android kernel patches), so these line do make much sense, but
> commenting them seems to change nothing.
> The question is should we integrate this driver from google kernel sources?
Our kernel is just derived from Google android kernel.
It contains all necessary drivers to run android.
(otherwise it won't boot at all)
Actually /sys/android_power is an obsolete interface.
It probably has been removed since android kernel 2.6.32.
Modern android phones don't use it at all.
The modern interface is /sys/power.
Probably we should just remove those lines in init.rc.
I guess Google keeps them because some platform
(e.g. goldfish emulator) running old kernel 2.6.29
still use it.
--
Chih-Wei
Android-x86 project
http://www.android-x86.org
Christopher Hrabia
Chih-Wei Huang
> It is the culprit on my device! You should try!
Well, how can I try? I don't have your device. :p
And seems you didn't state which device you're testing.
Even what you said is true, it's just a problem occurs on
honeycomb-x86. Check init.rc in android-x86 2.2, 2.3 and 4.0.
They don't have that line (onrestart restart surfaceflinger).
Do you mean suspend/resume works well in
2.2, 2.3 and 4.0 on your device?
I think your device has a different problem than
I've seen. It probably restart zygote on resume.
I don't see this behavior on my eeepc or tegav2.
Suspend/resume is a very complex problem.
Different platforms have different problems.
I don't think there is a general solution to all devices.
I even saw some device just hang on suspend --
it never resume back. It's probably be a kernel bug.
Anyway, thanks for pointing out a problem
in init.rc and providing a patch.
I'll apply it later.
> 2012/1/7 Chih-Wei Huang <cwh...@android-x86.org>
>>
>> I don't think it's the culprit of suspend/resume issue.
>> Actually on resume zygote is not restarted.
>> However, it's reasonable to remove that line,
>> as explained above.
--
Chih-Wei Huang
> Anyway, thanks for pointing out a problem
> in init.rc and providing a patch.
> I'll apply it later.
Applied. Thanks again!
rvdb
About suspend/resume as I "solved" it for the wetab/exopc:
First I needed to delete the (old) acpi_sleep= from the boot command
line.
After this I could wake the device by pressing power button AND
keeping my finger
on the touch screen.
Without this the device would go directly to sleep again.
I investigated the problem and found out that because of the way
Android is designed
(go to sleep if nothing is happening) and the power button was not
propagated to
android, no wake-locks where set, so back to sleep.
The reason for this is that pressing power button on a ACPI system is
not
propagated to the OS (as per ACPI-V3 design). It is possible to patch
the kernel so it will.
But I decided to do this another way.
I changed the powerbtn deamon to emulate a power button on resume (In
a dirty way for now).
But then I noticed that EventHub (honeycomb) is filtering this button
during resume, because
the ANDROID_VT is not yet up and running. I removed this from
EventHub, and now resume is keeping
the device awake.
(I also emulated a long pressure by two short pressures, because my
button only does
a short press).
Maybe this is helpfull for some other devices.
Greetings René
Chih-Wei Huang
ALoGeNo
Cheers.