Mir

integration-tests hang/fail in AndroidGPUDisplay.gpu_display_ok_with_gles when the display is asleep: what(): error posting with fb device

Bug #1239955 reported by Daniel van Vugt
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Mir
Fix Released
Medium
Unassigned

Bug Description

On Nexus 4, if you start with the display asleep...

./integration-tests
...
[ RUN ] AndroidGPUDisplay.gpu_display_ok_with_gles
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
  what(): error posting with fb device

See original description

Related branches

lp:~robertcarr/mir/android-test-powerd-cli
Rejected for merging into lp:mir
Daniel van Vugt: Disapprove
Alan Griffiths: Abstain
PS Jenkins bot (community): Approve (continuous-integration)
Diff: 36 lines (+6/-2)
2 files modified
debian/control (+1/-0)
debian/rules (+5/-2)
Superseded for merging into lp:mir/0.1
Daniel van Vugt: Needs Resubmitting
PS Jenkins bot (community): Approve (continuous-integration)
Diff: 36 lines (+6/-2)
2 files modified
debian/control (+1/-0)
debian/rules (+5/-2)
lp:~alan-griffiths/mir/workaround-1239955
Andreas Pokorny (community): Approve
Kevin DuBois (community): Approve
Alexandros Frantzis (community): Approve
PS Jenkins bot (community): Approve (continuous-integration)
Diff: 13 lines (+2/-1)
1 file modified
tests/integration-tests/graphics/android/test_display_integration.cpp (+2/-1)
lp:~alan-griffiths/mir/revert-workaround-1239955
Superseded for merging into lp:mir
PS Jenkins bot (community): Needs Fixing (continuous-integration)
Mir development team: Pending requested
Diff: 13 lines (+1/-2)
1 file modified
tests/integration-tests/graphics/android/test_display_integration.cpp (+1/-2)
Daniel van Vugt (vanvugt)
description: updated
Changed in mir:
importance: High → Medium
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Looks like bug 1188504 wasn't really fixed.

summary: integration-tests hang/fail in
- AndroidGPUDisplay.gpu_display_ok_with_gles: what(): error posting
- with fb device
+ AndroidGPUDisplay.gpu_display_ok_with_gles when the display is asleep:
+ what(): error posting with fb device
Daniel van Vugt (vanvugt)
tags: added: nexus4
Revision history for this message
Robert Carr (robertcarr) wrote :

It presents to me like this...a quite strange series of symptoms:

1. Start phone, stop unity8 (while the screen is ON).
2. Run integration tests, succeeds.
3. start unity8, repeat these steps, works every time

On the other hand
1. Start phone. stop unity8 (while the screen is OFF)
2. Run integration tests, fail with this error
3. Over and over :p

The particularly strange bit, is even though unity8 is dead, if you press the physical power button, the integration tests will pass, and the binary will fail to exit (haven't found out why yet).

Due to this last symptom I blame preemptively blame powerd for messing with the backlight or some sort of display state or something and HWC behaving weirdly as a result (Where else could the power button press come in to play?). Investigating deeper.

Revision history for this message
Robert Carr (robertcarr) wrote :

Did some more digging.

It seems the culprit is actually some unpolishedinteraction between powerd, earlysuspend and mir.

When turning the screen off, the earlysuspend state is set through powerd. See libsuspend/ in powerd for the details, but effectively on nexus 4 this ends up writing "mem" to /sys/power/state. This seems to turn off the display itself!

You can observe:
echo "mem" > /sys/power/state
mir/integration-tests # Fails to post to FB device
cat /sys/power/wait_for_fb_wake # Will Block Indefinitely

On the other hand
echo "on" > /sys/power/state
mir/integration-tests: Suceeeds
cat /sys/power/wait_for_fb_wake # Returns immediately

Trying to work out how to best coordinate a fix. As a work around, we could of course just run "powerd-cli active" during the mir tests, to ensure we keep have this "on" state.

Daniel van Vugt (vanvugt)
Changed in mir:
assignee: nobody → Robert Carr (robertcarr)
Daniel van Vugt (vanvugt)
Changed in mir:
assignee: Robert Carr (robertcarr) → nobody
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

See also: bug 1253179

Daniel van Vugt (vanvugt)
tags: added: blockingci
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

This now seems to be causing persistent CI failures as it behaves differently since trusty-proposed 119.

What I find trying this locally is...

echo "on" > /sys/power/state - has no effect.

Hitting the physical power button allows the test to pass.

Initially I saw intermittent failures if unity8 wasn't stopped - but hitting the power button before each run seems to ensure success.

Changed in mir:
importance: Medium → Critical
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

NB if investigating this you'll probably trip over lp:1249019 at some point.

Revision history for this message
Kevin DuBois (kdub) wrote :

If the display is indeed asleep (meaning, not blank/unblank, but rather the device has not come out of earlysuspend yet), this is an appropriate error, is it not?

Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

> If the display is indeed asleep (meaning, not blank/unblank, but rather the device
> has not come out of earlysuspend yet), this is an appropriate error, is it not?

The error message may well be appropriate - the test failure isn't. If the test has a precondition that the display is awake then we either the precondition should be met or the test is wrong.

We could have a test that checks that we get a meaningful error when the display is asleep.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Dropped severity as a workaround has landed (r1323).

Changed in mir:
importance: Critical → Medium
Daniel van Vugt (vanvugt)
tags: added: mako
Revision history for this message
Alexandros Frantzis (afrantzis) wrote :

The test doesn't exist anymore. Closing.

Changed in mir:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.