Sometimes resuming leaves only a black lit screen, no unity8

[Michael Terry]

Sometimes when I turn my dogfooding mako device on (running stable channel), I see a back lighted screen, but no unity8. It stays like that indefinitely, and I just have to hard-reset.

I haven't noticed any obvious correlations to the behavior. It just happens.

[Michael Terry (mterry)]

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 thread timing.

Consider:
- Main powerd thread writes to /sys/power/state
- Kernel does it's thing, maybe takes a while, updates /sys/power/state
- Listening powerd thread notices FB_AWAKE state, locks mutex, emits cond_signal, and then blocks waiting for FB_SLEEP state
- Main powerd thread enters the mutex locking section, locks mutex, waits for FB_AWAKE signal (that it missed)

Now powerd is blocked forever until someone else writes to /sys/power/state, right?

If powerd simply locked the mutex before writing to /sys/power/state, the listening thread would be forced to wait to update fb_state until the main thread gave up the lock via pthread_cond_wait and no one would miss any cond_signals.

(Threading is not my forte, so I'm probably missing something.)

[Michael Terry (mterry)]

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

[Seth Forshee (sforshee)]

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 describe is impossible. If the monitor thread changes fb_state to FB_AWAKE before the main thread locks the mutex, it will see fb_state == FB_AWAKE on the first loop iteration and never call pthread_cond_wait(). If the main thread locks the mutex before the monitor thread changes the state then the monitor thread cannot change the state until pthread_cond_wait() releases the mutex, then the subsequent pthread_cond_signal() call will awaken the main thread.

[Michael Terry (mterry)]

Ah good point, I forgot we check fb_state *before* doing cond_wait. :(