847207 - failure to lock gralloc buffer for shadow layer doesn't fall back to using shmem

Status: RESOLVED DUPLICATE of bug 849515

(Core :: Graphics: Layers, defect)

Description

[Andreas Gal :gal]

My phone doesn't start up occasionally. I suspected that the disk is full, but thats not the case. Turns out we are actually failing to lock a gralloc buffer and we don't fall back onto shmem and we don't render anything. I am not sure why this only failed occasionally and why this went away from reinstalling gecko a few times. My best guess is that the disk layout changed and gecko became minimally slower to load, or some other cause that resolved the race condition with the boot animation differently. It would be good if our silicon friends could debug why lock fails here exactly. This is on the ZTE Open.

Comment 1

[Andreas Gal :gal]

Attachment: patch

Comment 2

[Andreas Gal :gal]

Kanru, can you please land if you agree with the approach?

Comment 3

[Andreas Gal :gal]

I am blocking for the vendor on this one, because I am very sure they want this fixed. I will confirm though.

Silicon vendor engineering friends, please try to reproduce and figure out why the lock() fails here.

Comment 4

[Diego Wilson [:diego]]

My ZTE Open starts up pretty consistently. I rebooted it 20 times in a row successfully. How often does it happen to you?

Can anyone else reproduce it? Any chance the Mozilla builds replace any of the graphics libraries?

Comment 5

[Kan-Ru Chen [:kanru] (UTC+9)]

Comment on attachment 720459 [details] [diff] [review]
patch

Review of attachment 720459 [details] [diff] [review]:
-----------------------------------------------------------------

That means we might be locking the buffer for writing simultaneously. We should change the assert to a warning and fix the real issue in a follow-up.

Comment 6

[Andreas Gal :gal]

Diego, when the device gets moody, it doesn't start up at all. Are you seeing the error messages I reported?

Comment 7

[Andreas Gal :gal]

I am not seeing the same issues with the GP device. This seems to be specific to that vendor's kernel.

Comment 8

[Andreas Gal :gal]

I flashed a trunk build onto my GP device and its definitely not showing any of the symptoms, including the failure this patch was trying to fix. This is definitely a vendor issue. My best guess is something is wrong with the kernel genlock device. Diego can you please check logcat?

Comment 9

[Diego Wilson [:diego]]

I don't see any gralloc or genlock errors in logcat.

FYI my ZTE Open kernel was last updated on February 21st

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

Diego, if this is a kernel issue, should it go to you?

Comment 11

[Diego Wilson [:diego]]

(In reply to Milan Sreckovic [:milan] from comment #10)
> Diego, if this is a kernel issue, should it go to you?

For kernel issues you should go to the OEM

Comment 12

[Michael Wu [:mwu]]

I see a similar issue on the keon with a trunk build, but not on the open. I think it might be a regression in gecko.

Comment 13

[Alex Keybl [:akeybl]]

(In reply to Michael Wu [:mwu] from comment #12)
> I see a similar issue on the keon with a trunk build, but not on the open. I
> think it might be a regression in gecko.

Since you're able to repro, sending over to you to help determine whether the issue is on our side.

Comment 14

[Firefox_Mozilla]

similar with bug 849515?

Comment 15

[Michael Wu [:mwu]]

Andreas, I checked in a fix on bug 849515, which I suspect is the same issue as this. I'm duping this bug to that one, but if it still happens, please reopen.