nexus 4 client lock up observed

So what is happening is:

hwc::commit ({layer1, layer2})
and then
hwc::commit({layer2, layer1}).

Since both layer 1 and layer 2 are already onscreen, the hwc has already accepted their acquireFenceFd's and programmed them with new releaseFenceFd's after the 1st commit.

When the 2nd commit comes around, the mir code fails to recognize that the layers have already been accepted by hwc and copies the releaseFenceFd into the acquireFenceFd for the 2nd commit. Since the 2nd commit is the precipitating event that signals the releaseFenceFd's from the 1st commit, the second commit hangs (pausing the renderloop).

The reason why this is intermittent is that the fences will time out after a device-specific time interval, at which point the timeout unblocks the renderloop and the system will continue.

"The reason why this is intermittent is that the fences will time out after a device-specific time interval, at which point the
timeout unblocks the renderloop and the system will continue."
* the reason why the loop will continue after a short time

The reason why this is _intermittent_ is that this scenario does not happen frequently, and even when it does, it depends on the specific timing of the buffers coming from the BufferQueue as to whether this will deadlock.

Fix committed into lp:mir/devel at revision None, scheduled for release in mir, milestone Unknown

Fix released in Mir 0.6.1+14.10.20140814-0ubuntu1 package.

mir (0.6.1+14.10.20140814-0ubuntu1) utopic; urgency=medium

This bug does not exist in Mir 0.7, because the fix was released in the 0.6 series before 0.7 branched from it. However a separate fix exists in development-branch so it's still not "Fix Released" for 0.8 just yet.