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 on 2013-10-15
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

Related branches

description: updated
Changed in mir:
importance: High → Medium
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
tags: added: nexus4
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.

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.

Changed in mir:
assignee: nobody → Robert Carr (robertcarr)
Changed in mir:
assignee: Robert Carr (robertcarr) → nobody
Daniel van Vugt (vanvugt) wrote :

See also: bug 1253179

tags: added: blockingci
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
Alan Griffiths (alan-griffiths) wrote :

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

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?

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.

Daniel van Vugt (vanvugt) wrote :

Dropped severity as a workaround has landed (r1323).

Changed in mir:
importance: Critical → Medium
tags: added: mako

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  Edit
Everyone can see this information.

Other bug subscribers