diff options
author | Bill Richardson <wfrichar@chromium.org> | 2014-11-21 10:29:29 -0800 |
---|---|---|
committer | chrome-internal-fetch <chrome-internal-fetch@google.com> | 2014-11-22 09:34:23 +0000 |
commit | 3483f0b1dd368a3f250b24ce0a0920e1627a5592 (patch) | |
tree | cd3f6a7707fe8fb3037feb028e8f56f15b8bc0e1 /OWNERS | |
parent | afc9090d7e7742cf770a25318514a05325b2bdcc (diff) | |
download | chrome-ec-3483f0b1dd368a3f250b24ce0a0920e1627a5592.tar.gz |
Stop mutex_lock() from eating pending events
When another task is holding the lock, mutex_lock() should call
task_wait_event_mask() to wait only for TASK_EVENT_MUTEX events.
If it calls task_wait_event(), any pending events are silently
discarded while its waiting for the the lock.
BUG=chromium:435611
BRANCH=ToT,samus
TEST=make buildall -j, and:
Before this change, I watched the EC console while shutting down
and rebooting Samus. I saw the request event arrive:
[37.576295 LB lightbar_resume() requests 5 S3S0]
[46.055725 LB_version]
But the lightbar task never saw it. Adding a bunch of debug
messages showed that it was being lost in mutex_lock().
After this change, the event is delivered:
[30.167670 LB lightbar_resume() requests 5 S3S0]
[30.171009 LB cur_seq 2 S3 returned pending msg 5 S3S0]
[30.173816 LB running cur_seq 5 S3S0. prev_seq 2 S3]
[32.410073 LB cur_seq 5 S3S0 returned value 0]
[32.410865 LB running cur_seq 3 S0. prev_seq 2 S3]
[39.938388 LB_version]
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I011838538960cc57171f0a3c4cdee113d156e9ff
Reviewed-on: https://chromium-review.googlesource.com/231370
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Diffstat (limited to 'OWNERS')
0 files changed, 0 insertions, 0 deletions