touch-packages team mailing list archive

[Michael Terry <michael.terry@xxxxxxxxxxxxx>]

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.)

-- 
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 black lit screen, no unity8

Status in powerd package in Ubuntu:
  New
Status in unity8 package in Ubuntu:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/powerd/+bug/1450017/+subscriptions