[Dev] 答复: Kernel build issue: hikey-mali branch fails to build...

xinliang xin3liang at qq.com
Tue Apr 21 08:24:11 UTC 2015


Loop shaozhen.

On Tuesday, April 21, 2015 04:02 PM, xinliang wrote:
> Hi, I rebuild the gralloc lib with the libgralloc.patch(please find it 
> in the attached file) , which remove all the hisilicon's private code.
> I can load gralloc and gpu libs sucessfully. But encounter bellow issue:
>
> [   28.341733] ------------[ cut here ]------------
> [   28.346420] WARNING: CPU: 1 PID: 1688 at 
> drivers/staging/android/sync.c:433 android_fence_release+0xf0/0x100()
> [   28.356428] Modules linked in:
> [   28.359497] CPU: 1 PID: 1688 Comm: surfaceflinger Not tainted 
> 3.18.0-linaro-hikey #5
> [   28.367240] Call trace:
> [   28.369692] [<ffffffc000088630>] dump_backtrace+0x0/0x140
> [   28.375093] [<ffffffc000088780>] show_stack+0x10/0x1c
> [   28.380149] [<ffffffc000835b10>] dump_stack+0x74/0xb8
> [   28.385202] [<ffffffc0000b0114>] warn_slowpath_common+0x90/0xb4
> [   28.391121] [<ffffffc0000b01fc>] warn_slowpath_null+0x14/0x20
> [   28.396870] [<ffffffc0006b5e64>] android_fence_release+0xec/0x100
> [   28.402988] [<ffffffc00054f720>] fence_release+0x44/0xfc
> [   28.408309] [<ffffffc0006b6090>] sync_fence_free+0x88/0xb4
> [   28.413799] [<ffffffc0006b60f0>] sync_fence_release+0x34/0x48
> [   28.419571] [<ffffffc0001c3988>] __fput+0x8c/0x1d4
> [   28.424367] [<ffffffc0001c3b24>] ____fput+0x8/0x14
> [   28.429160] [<ffffffc0000caa90>] task_work_run+0x94/0xec
> [   28.434473] [<ffffffc0000881ec>] do_notify_resume+0x54/0x68
> [   28.440045] ---[ end trace 34fb9bc92eafeafb ]---
>
> And with addr2line tool i address on line 433 of 
> file:drivers/staging/android/sync.c:433
> 425 static void android_fence_release(struct fence *fence)
> 426 {
> 427         struct sync_pt *pt = container_of(fence, struct sync_pt, 
> base);
> 428         struct sync_timeline *parent = sync_pt_parent(pt);
> 429         unsigned long flags;
> 430
> 431         spin_lock_irqsave(fence->lock, flags);
> 432 list_del(&pt->child_list);
> 433         if (WARN_ON_ONCE(!list_empty(&pt->active_list)))
> 434 list_del(&pt->active_list);
>
> I attach the kernel and logcat log.
> Does zixin and anybody who know what's the problem is?
>
> Best Regards,
> -Xinliang
>
>
> On Wednesday, April 08, 2015 07:23 PM, xinliang wrote:
>>
>>
>> On Tuesday, April 07, 2015 05:08 PM, Vishal Bhoj wrote:
>> Hi Vishal, I am working with my colleagues on the rebuilding of ion and gralloc libs.
>> There are some difference between corrent hikey kernel and product kernel on ion driver.
>> we need some time to handle this difference in order to rebuild a work ion and gralloc lib.
>>
>> Best regards,
>> Xinliang
>>> ping ! Any ETA on the recompiled libion lib?
>>>
>>> On 31 March 2015 at 11:39, Xuzixin <xuzixin at hisilicon.com 
>>> <mailto:xuzixin at hisilicon.com>> wrote:
>>>
>>>     loop ZhaoDan
>>>
>>>     *发 件 人:*xinliang [mailto:xin3liang at qq.com
>>>     <mailto:xin3liang at qq.com>]
>>>     *发 送 时间:*2015年3月30日11:11
>>>     *收件人:*Xuzixin
>>>     *抄送:*Vishal Bhoj; Guillaume.Tucker; dev
>>>     *主题:*Re: [Dev] Kernel build issue: hikey-mali branch fails to
>>>     build...
>>>
>>>     Loop zhixin,
>>>
>>>     On Monday, March 30, 2015 11:00 AM, Vishal Bhoj wrote:
>>>
>>>         Hi,
>>>
>>>         On 30 March 2015 at 07:57, xinliang <xin3liang at qq.com
>>>         <mailto:xin3liang at qq.com>> wrote:
>>>
>>>         On Monday, March 30, 2015 12:00 AM, Vishal Bhoj wrote:
>>>
>>>             On 29 March 2015 at 21:07, Vishal Bhoj
>>>             <vishal.bhoj at linaro.org <mailto:vishal.bhoj at linaro.org>>
>>>             wrote:
>>>
>>>             I have compiled the Mali kernel module for Android and
>>>             tried to boot Android based on Scott's proposed change.I
>>>             am able to load the mali kernel module but I am getting
>>>             an error while surfaceflinger tries load the GLES libs
>>>             and use the same. The logcat and dmesg output is here:
>>>
>>>             https://pastebin.linaro.org/view/93ad6748
>>>
>>>             Did some changes to pick the right gralloc lib and the
>>>             ion library. It still fails. Here is the logcat:
>>>
>>>             https://pastebin.linaro.org/view/6e7d5ca4
>>>
>>>             Gralloc tries to request fb with triplebuffering
>>>             configuration but current FB is configured for single
>>>             buffer (looks like):
>>>
>>>             <3>[ 51.649450] [drm:hisi_drm_fb_helper_check_var]
>>>             *ERROR* fb userspace request width/height/bpp is greater
>>>             than current fb request 1280x720-32 (virtual 1280x2160)
>>>             > 1280x1440-32
>>>
>>>             <7>[ 81.907649] calling  init_module+0x0/0x6c [mali] @ 1755
>>>
>>>             <6>[ 81.908408] ion: heap info : id 10 name fb phy
>>>             0x37300000 size 26214400
>>>
>>>             <4>[ 81.917596] Mali: GPU version: CF070000
>>>
>>>             <4>[ 81.930435] Mali: Mali device driver loaded
>>>
>>>             <7>[ 81.934911] initcall init_module+0x0/0x6c [mali]
>>>             returned 0 after 26431 usecs
>>>
>>>             <14>[  101.000830] healthd: battery none chg=
>>>
>>>             <3>[  111.007480] [drm:hisi_drm_fb_helper_check_var]
>>>             *ERROR* fb userspace request width/height/bpp is greater
>>>             than current fb request 1280x720-32 (virtual 1280x2160)
>>>             > 1280x1440-32
>>>
>>>         Please open this file:
>>>         drivers/gpu/drm/hisilicon/hisi_drm_fb.h and change bellow
>>>         macro value to 3 then we can get triplebuffer. Please have a
>>>         try. Thanks.
>>>         15 #define HISI_NUM_FRAMEBUFFERS 2
>>>
>>>         Thanks ! I don't see the FB related error not but I still
>>>         get the ION errors:
>>>
>>>         E/ion     ( 2111): ioctl fd 10 c0404908(unknown) failed with
>>>         code -1: Invalid argument
>>>
>>>         E/ion     ( 2111): map iommu failed!
>>>
>>>         E/[Gralloc-ERROR]( 2111): int
>>>         alloc_backend_alloc(alloc_device_t*, int, int, size_t, int,
>>>         const native_handle_t**):101 ion_map_iommu( 10 ) failed,
>>>         usage ( 1e02 ), byte_w ( 8192 )
>>>
>>>         W/GraphicBufferAllocator( 2111): alloc(1280, 720, 1,
>>>         00001e02, ...) failed -1 (Operation not permitted)
>>>
>>>         E/        ( 2111):
>>>         GraphicBufferAlloc::createGraphicBuffer(w=1280, h=720)
>>>         failed (Operation not permitted), handle=0x0
>>>
>>>         E/BufferQueueProducer( 2111): [FramebufferSurface]
>>>         dequeueBuffer: createGraphicBuffer failed
>>>
>>>     @xuzixin current ion doesn't use iommu and we use reserved
>>>     memory instead. Could you please rebuild an ion lib that alloc
>>>     memory in reserved way? Thanks.
>>>
>>>     E/[EGL-ERROR]( 2111): void
>>>     __egl_platform_dequeue_buffer(egl_surface*):1609: failed to
>>>     dequeue buffer from native window 0x7fb6b1be10; err = -1, buf =
>>>     0x0,max_allowed_dequeued_buffers 2
>>>
>>>     E/libEGL  ( 2111): eglMakeCurrent:777 error 3003 (EGL_BAD_ALLOC)
>>>
>>>     E/libEGL  ( 2111): call to OpenGL ES API with no current context
>>>     (logged once per thread)
>>>
>>>     D/SurfaceFlinger( 2111): Set power mode=2, type=0
>>>     flinger=0x7fb7764000
>>>
>>>     E/BufferQueueProducer( 2111): [FramebufferSurface]
>>>     dequeueBuffer: can't dequeue multiple buffers without setting
>>>     the buffer count
>>>
>>>     E/[EGL-ERROR]( 2111): void
>>>     __egl_platform_dequeue_buffer(egl_surface*):1609: failed to
>>>     dequeue buffer from native window 0x7fb6b1be10; err = -38, buf =
>>>     0x0,max_allowed_dequeued_buffers 2
>>>
>>>     E/libEGL  ( 2111): eglMakeCurrent:777 error 3003 (EGL_BAD_ALLOC)
>>>
>>>     W/SurfaceFlinger( 2111): DisplayDevice::makeCurrent failed.
>>>     Aborting surface composition for display Built-in Screen
>>>
>>>     E/BufferQueueProducer( 2111): [FramebufferSurface]
>>>     dequeueBuffer: can't dequeue multiple buffers without setting
>>>     the buffer count
>>>
>>>     E/[EGL-ERROR]( 2111): void
>>>     __egl_platform_dequeue_buffer(egl_surface*):1609: failed to
>>>     dequeue buffer from native window 0x7fb6b1be10; err = -38, buf =
>>>     0x0,max_allowed_dequeued_buffers 2
>>>
>>>     E/libEGL  ( 2111): eglMakeCurrent:777 error 3003 (EGL_BAD_ALLOC)
>>>
>>>     E/SurfaceFlinger( 2111): DisplayDevice::makeCurrent on default
>>>     display failed. Aborting.
>>>
>>>     E/BufferQueueProducer( 2111): [FramebufferSurface]
>>>     dequeueBuffer: can't dequeue multiple buffers without setting
>>>     the buffer count
>>>
>>>     E/[EGL-ERROR]( 2111): void
>>>     __egl_platform_dequeue_buffer(egl_surface*):1609: failed to
>>>     dequeue buffer from native window 0x7fb6b1be10; err = -38, buf =
>>>     0x0,max_allowed_dequeued_buffers 2
>>>
>>>     E/libEGL  ( 2111): eglMakeCurrent:777 error 3003 (EGL_BAD_ALLOC)
>>>
>>>     Is there source available for gralloc and libion ? Can someone
>>>     in Hisilicon LT help with this ?
>>>
>>>                 Regards,
>>>
>>>                 Vishal
>>>
>>>                 On 27 March 2015 at 19:02, Guillaume Tucker
>>>                 <guillaume.tucker at arm.com
>>>                 <mailto:guillaume.tucker at arm.com>> wrote:
>>>
>>>
>>>                     On 26/03/15 17:48, Jorge Ramirez-Ortiz wrote:
>>>
>>>                     On 03/26/2015 11:15 AM, Scott Bambrough wrote:
>>>
>>>                     I've been going around with Jorge for a couple
>>>                     of days with this.  He
>>>                     doesn't see the error but I do using make 4.0. 
>>>                     I have spoken with
>>>                     Vishal and he sees this error with make 3.81,
>>>                     and tells me Fathi sees
>>>                     this error in local builds.
>>>
>>>
>>>                     Works for me with GNU Make 3.81 on Ubuntu
>>>                     12.04.  I didn't remove
>>>                     anything from Kbuild in the patch I sent you as
>>>                     I didn't hit this issue,
>>>                     but the bit of logic involved only tends to make
>>>                     sense when the driver
>>>                     is built out-of-tree. So in this context I think
>>>                     it can be simplified
>>>                     as Scott suggested (i.e. by removing the license
>>>                     test) as we know it's
>>>                     all GPL.
>>>
>>>                         on my side it builds fine (I havent been
>>>                         able to reproduce the error using the
>>>                         following)
>>>
>>>                         [jramirez at calypso-2 ~]$ cat /etc/lsb-release
>>>                         DISTRIB_ID=Ubuntu
>>>                         DISTRIB_RELEASE=14.04
>>>                         DISTRIB_CODENAME=trusty
>>>                         DISTRIB_DESCRIPTION="Ubuntu 14.04.2 LTS"
>>>
>>>                         [jramirez at calypso-2 ~]$ make -v
>>>                         GNU Make 3.81
>>>                         Copyright (C) 2006  Free Software
>>>                         Foundation, Inc.
>>>                         This is free software; see the source for
>>>                         copying conditions.
>>>                         There is NO warranty; not even for
>>>                         MERCHANTABILITY or FITNESS FOR A
>>>                         PARTICULAR PURPOSE.
>>>
>>>                         This program built for x86_64-pc-linux-gnu
>>>
>>>
>>>                         and
>>>                         [jramirez at calypso ~]$ cat /etc/lsb-release
>>>                         DISTRIB_ID=Ubuntu
>>>                         DISTRIB_RELEASE=14.10
>>>                         DISTRIB_CODENAME=utopic
>>>                         DISTRIB_DESCRIPTION="Ubuntu 14.10"
>>>
>>>                         [jramirez at calypso ~]$ make -v
>>>                         GNU Make 4.0
>>>                         Built for x86_64-pc-linux-gnu
>>>                         Copyright (C) 1988-2013 Free Software
>>>                         Foundation, Inc.
>>>                         License GPLv3+: GNU GPL version 3 or later
>>>                         <http://gnu.org/licenses/gpl.html>
>>>                         This is free software: you are free to
>>>                         change and redistribute it.
>>>                         There is NO WARRANTY, to the extent
>>>                         permitted by law.
>>>
>>>                     -- IMPORTANT NOTICE: The contents of this email
>>>                     and any attachments are confidential and may
>>>                     also be privileged. If you are not the intended
>>>                     recipient, please notify the sender immediately
>>>                     and do not disclose the contents to any other
>>>                     person, use it for any purpose, or store or copy
>>>                     the information in any medium. Thank you.
>>>
>>>                     ARM Limited, Registered office 110 Fulbourn
>>>                     Road, Cambridge CB1 9NJ, Registered in England &
>>>                     Wales, Company No:  2557590
>>>                     ARM Holdings plc, Registered office 110 Fulbourn
>>>                     Road, Cambridge CB1 9NJ, Registered in England &
>>>                     Wales, Company No:  2548782
>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.96boards.org/pipermail/dev/attachments/20150421/3b8fdd4a/attachment.html>


More information about the Dev mailing list