Closed Bug 847207 Opened 10 years ago Closed 10 years ago
failure to lock gralloc buffer for shadow layer doesn't fall back to using shmem
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.
Kanru, can you please land if you agree with the approach?
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.
blocking-b2g: --- → tef+
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 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.
Attachment #720459 - Flags: review?(kchen) → review+
Diego, when the device gets moody, it doesn't start up at all. Are you seeing the error messages I reported?
I am not seeing the same issues with the GP device. This seems to be specific to that vendor's kernel.
10 years ago
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?
I don't see any gralloc or genlock errors in logcat. FYI my ZTE Open kernel was last updated on February 21st
Diego, if this is a kernel issue, should it go to you?
(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
10 years ago
Assignee: nobody → mvines
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.
(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.
Assignee: nobody → mwu
similar with bug 849515?
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 849515
You need to log in before you can comment on or make changes to this bug.