Closed Bug 849515 Opened 8 years ago Closed 8 years ago
_]Boot failed with genlock error
User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.24 Safari/534.7 Steps to reproduce: Make a build using the latest code Load the image to the device Boot up the device Actual results: The device can not boot successfully, staying on the boot screen Expected results: The device should boot successfully
attachment is logcat output. From the logcat message, I found these error: I/Gecko ( 111): -*- QCContentHelper_QC_B2G: system message listener is now ready E/libgenlock( 111): perform_lock_unlock_operation: GENLOCK_IOC_LOCK failed (lockType0x1, err=Invalid argument fd=15) E/msm7627a.gralloc( 111): gralloc_lock: genlock_lock_buffer (lockType=0x2) failed W/Gonk ( 111): Failed to lock buffer_handle_t E/libgenlock( 111): perform_lock_unlock_operation: GENLOCK_IOC_LOCK failed (lockType0x1, err=Invalid argument fd=15) E/msm7627a.gralloc( 111): gralloc_lock: genlock_lock_buffer (lockType=0x2) failed W/Gonk ( 111): Failed to lock buffer_handle_t E/WifiHW ( 111): 'AP_SCAN 1' W/Adreno200-EGLSUB( 111): <GetBackBuffer:1903>: genlock_wait failed E/Adreno200-EGL( 111): <qeglDrvAPI_eglSwapBuffers:3388>: EGL_BAD_ALLOC E/HWComposer( 111): Hardware device failed to render E/libgenlock( 111): genlock_wait: GENLOCK_IOC_WAIT failed (err=Connection timed out) W/Adreno200-EGLSUB( 111): <GetBackBuffer:1903>: genlock_wait failed E/Adreno200-EGL( 111): <qeglDrvAPI_eglSwapBuffers:3388>: EGL_BAD_ALLOC D/memalloc( 111): /dev/pmem: Allocated buffer base:0x4bf23000 size:12288 offset:1466368 fd:140 D/memalloc( 400): /dev/pmem: Mapped buffer base:0x45800000 size:1478656 offset:1466368 fd:45 I/Adreno200-EGLSUB( 111): <CreateImage:896>: Android Image ========================= 1) the build is based on the below commit: gecko: 3916db8cb84dce2afd90c01254692c33078b8b68 gaia: 91ad7fb9dc82e87021a2bac5900f2dd91f124405 2) I tried to disable boot animation(removing /system/media/bootanimation.zip), and the error would not happen 3) tried to disable hwcomposer, the bug is still existing 4) build from the below commit works well gaia: a41c7921fbf0839b894f277261dad4a22507f979 gecko: b3cd9efc36ce4556117c56ae11807d839023f603
Severity: normal → blocker
OS: All → Gonk (Firefox OS)
Priority: -- → P1
Hardware: All → ARM
similar with Bug 821480 ?
blocking-b2g: --- → tef+
Assignee: nobody → dwilson
@Cyvins In what device and branch are you seeing this?
(In reply to Diego Wilson [:diego] from comment #3) > @Cyvins In what device and branch are you seeing this? wrt. branch, please just provide the AU number that this is seen on.
I am using the v790 device,and both AU30,AU31 have this issue, AU27 does not have such issue, the current cdr code is AU31. thanks.
it's v1.0.1 branch.
(In reply to cyvins from comment #5) > I am using the v790 device,and both AU30,AU31 have this issue, AU27 does not > have such issue, the current cdr code is AU31. thanks. I'm not familiar with that device. Who's the OEM?
I will try kis device, I think it should have such issue, and Michael should have this v790 device.
Yep we have both. Should be able to check this here on Monday.
I loaded the latest from the v1.0.1 branch of gecko/gaia on the v790 device. I didn't see any gralloc error. @cyvins, what branch are you trying to test?
Hi, Diego Our build is based on the below commit of gecko/gaia, branch v1.0.1, AU31 gaia: revision="91ad7fb9dc82e87021a2bac5900f2dd91f124405" gecko: revision="3916db8cb84dce2afd90c01254692c33078b8b68" could tell me the commit id that you have tested? and did you load the image built from cdr or just update the gecko/gaia? Thanks.
do you think it is the same issue with bug 847207?
The problem goes away when I remove /system/media/bootanimation.zip. I noticed v790 builds have a splash.img. I haven't seen that in other equivalent devices. Any chance this bootanimation.zip and splash.img are somehow clashing?
Can someone try this patch and see if it fixes the issue? It works for me on the Keon, but I've had more difficulty reproducing on the open. This patch forces us to wait for the boot animation to finish animating before touching any opengles stuff on the gecko side. Currently, we only wait for the boot animation before attempting to draw, so gecko attempts to do opengl init in parallel.
The patch fixes my ZTE open. I say land it! :)
I will try it. Many thanks.
This issue can be fixed by the attached patch. Thanks.
Comment on attachment 726314 [details] [diff] [review] Wait for boot animation before initializing layer manager Andreas, do you mind reviewing this patch? I think we're a bit short on gonk widget peers. This patch forces the boot animation thread to stop running before attempting to initialize opengl. It stops the boot animation before we attempt to create an opengl layer manager. Apparently initializing opengl while the animation is running randomly causes bad things to happen.
Attachment #726314 - Flags: review?(gal)
Attachment #726314 - Flags: review?(gal) → review+
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Does not make sense to create a regression issue.
Verified as fixed in build: Kernel Date: Dec 5 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/ccec751a468e Gaia: ee0bef61c0a25c806dd1eec5a4e047bc418a5f73
You need to log in before you can comment on or make changes to this bug.