suspend / sleep on kitkat

[fuzzy7k]

Trying to figure out sleep and I think I figured out why it's not working, but not how to fix it.

connecting via abd
# cd /sys/power
# cat wake_lock > wake_unlock
# cat autosleep
off
...press sleep on the device
# cat autosleep
mem
# cat wakeup_count
425

So, if I understand this correctly, there are 425 wakeup sources active, and autosleep will not complete until there are 0. Furthermore, this number tends to increase while the screen is blanked. I'm starting to wonder if those devices on which sleep works, if it's not just blanking the display.

However, if I reboot and just do echo mem > /sys/power/state, it goes to sleep.

[fuzzy7k]

ok, so I discovered how to look at the wakeup sources: /sys/kernel/debug/wakeup_sources
The problem is, even if all of this worked and sources had proper expiration times, there would still always be a wakeup source when the device is manually put to sleep because pushing a button is a wakeup source. But, that is autosleep and I see that autosleep will be the replacement for earlysuspend, and we are still using earlysuspend.

So, there where two reasons suspend wasn't working for me. One, because of a conflict between SurfaceFlinger and the kernel caused by a bug, who knows where. On my device which uses radeon, after SurfaceFlinger blanks the screen the kernel hangs on pm_prepare_console. Disabling pm_prepare_console allows the device to go to sleep, but after wakeup the screen stays black. Doing it the other way, disabling the blank functionality in SurfaceFlinger allows pm_prepare_console to function normally and there is no issue with the screen not coming back.

The Second reason was a simple bug in the earlysuspend code introduced when the kernel started rejecting 'on' to /sys/power/state while the system is already on. Earlysuspend treats it as an error and doesn't run some code that it probably should.

side note: The bug in SurfaceFlinger might have something to do with the following error. From what I understand 20 refers to the VT. Not sure where 20 comes from, I would think it should be 7.
E/SurfaceFlinger( 1369): ioctl(20, VT_RELDISP, 1) failed 22 (Invalid argument)

[Chih-Wei Huang]

2014-03-04 20:21 GMT+08:00 fuzzy7k <kva...@gmail.com>:
> ok, so I discovered how to look at the wakeup sources:
> /sys/kernel/debug/wakeup_sources
> The problem is, even if all of this worked and sources had proper expiration
> times, there would still always be a wakeup source when the device is
> manually put to sleep because pushing a button is a wakeup source. But, that
> is autosleep and I see that autosleep will be the replacement for
> earlysuspend, and we are still using earlysuspend.
>
> So, there where two reasons suspend wasn't working for me. One, because of a
> conflict between SurfaceFlinger and the kernel caused by a bug, who knows
> where. On my device which uses radeon, after SurfaceFlinger blanks the
> screen the kernel hangs on pm_prepare_console. Disabling pm_prepare_console
> allows the device to go to sleep, but after wakeup the screen stays black.
> Doing it the other way, disabling the blank functionality in SurfaceFlinger
> allows pm_prepare_console to function normally and there is no issue with
> the screen not coming back.
>
> The Second reason was a simple bug in the earlysuspend code introduced when
> the kernel started rejecting 'on' to /sys/power/state while the system is
> already on. Earlysuspend treats it as an error and doesn't run some code
> that it probably should.

Thank you for the patches.
Will try to verify it later.

> side note: The bug in SurfaceFlinger might have something to do with the
> following error. From what I understand 20 refers to the VT. Not sure where
> 20 comes from, I would think it should be 7.
> E/SurfaceFlinger( 1369): ioctl(20, VT_RELDISP, 1) failed 22 (Invalid
> argument)

It's the consoleFd, not the vt number. See

frameworks/native/services/surfaceflinger/DisplayDevice.cpp

ALOGE_IF(err < 0, "ioctl(%d, VT_RELDISP, 1) failed %d (%s)",
consoleFd, errno, strerror(errno));



--
Chih-Wei
Android-x86 project
http://www.android-x86.org

[fuzzy7k]

> side note: The bug in SurfaceFlinger might have something to do with the
> following error. From what I understand 20 refers to the VT. Not sure where
> 20 comes from, I would think it should be 7.
> E/SurfaceFlinger( 1369): ioctl(20, VT_RELDISP, 1) failed 22 (Invalid
> argument)

It's the consoleFd, not the vt number. See

frameworks/native/services/surfaceflinger/DisplayDevice.cpp

    ALOGE_IF(err < 0, "ioctl(%d, VT_RELDISP, 1) failed %d (%s)",
        consoleFd, errno, strerror(errno));

That makes sense. I was reading documentation for the ioctl and probably misread, or didn't read all of it.
In any case, it's the only error I see in the logs so I thought it might be a symptom. Naturally, the error is not there with the patch to disable display blanking.

[Andrews Magnoni]

can you post the compiled files?
i dont even know how to compile these.
the screen is turning off on the login screen and never going back.
during the session i turned off the sleep.

[midi jari]

I don't know if this would help but it actually goes to sleep whenever I ask it to so so and to wake it I have to click on the Power buton twice (w/ a little lapse of ~1sec).

[Chih-Wei Huang]

Sorry for the late response.

I made tests for the patches on difference devices I have.
They improve some cases, but not resolve all issues.
Anyway, I think it's good enough to merge them.
I have pushed them in.
Thank you for the work.

2014-03-04 20:21 GMT+08:00 fuzzy7k <kva...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "Android-x86" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to android-x86...@googlegroups.com.
> To post to this group, send email to andro...@googlegroups.com.
> Visit this group at http://groups.google.com/group/android-x86.
> For more options, visit https://groups.google.com/groups/opt_out.

[Daniel Barrett]

Hi, sorry this may be a noob question... How do I obtain and apply this patch?

[fuzzy7k]

The patches apply to source code with the command 'git am .patch', but CW has just applied them. So, if you have the source, all you need to do is repo sync. Otherwise, you need to wait for a new release.

[rbg]

see https://groups.google.com/forum/#!searchin/android-x86/Nightly$20Builds/android-x86/goeHnK-o6AY/fJHYETmKKfwJ