OK, here's a wild theory. Looking at powerd/libsuspend/earlysuspend.c
and reading the 0.5s kernel delay comments in bug 1421455...
Why don't earlysuspend_exit and _enter lock the mutex before making the
sysfs_write call? Seems like they could miss the pthread_cond_signal
call depending on
Sorry, small typo. The second consider step should have been:
- Kernel does it's thing, maybe takes a while, updates
/sys/power/wait_for_fb_wake
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to powerd in Ubuntu.
Ah good point, I forgot we check fb_state *before* doing cond_wait. :(
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to powerd in Ubuntu.
https://bugs.launchpad.net/bugs/1450017
Title:
Sometimes resuming leaves only a
The powerd main thread only ever checks fb_state with the mutex locked,
and the monitor thread only ever changes it with the mutex locked. The
main thread also only calls pthread_cond_wait() *after* finding fb_state
!= FB_AWAKE *without any intervening unlock of the mutex.* So the
scenario you
4 matches
Mail list logo
