[Mesa-users] Testing VC4 on rpi2 with wayland and weston, weston fail to start with drm (trace translated with addr2line included)

Fabio Fantoni fabio.fantoni at m2r.biz
Tue Dec 22 07:33:52 PST 2015 

Il 18/12/2015 16:50, Fabio Fantoni ha scritto:
>
>
> Il 17/12/2015 20:01, Eric Anholt ha scritto:
>> Fabio Fantoni <fabio.fantoni at m2r.biz> writes:
>>
>>> Il 12/11/2015 11:29, Fabio Fantoni ha scritto:
>>>>
>>>> Il 06/11/2015 14:15, Fabio Fantoni ha scritto:
>>>>>
>>>>> Il 05/11/2015 03:36, Eric Anholt ha scritto:
>>>>>> Fabio Fantoni <fabio.fantoni at m2r.biz> writes:
>>>>>>
>>>>>>> Il 30/10/2015 18:49, Eric Anholt ha scritto:
>>>>>>>> Fabio Fantoni <fabio.fantoni at m2r.biz> writes:
>>>>>>>>
>>>>>>>>> Il 25/10/2015 15:32, Fabio Fantoni ha scritto:
>>>>>>>>>> Il 07/10/2015 00:01, Eric Anholt ha scritto:
>>>>>>>>>>> Fabio Fantoni <fabio.fantoni at m2r.biz> writes:
>>>>>>>>>>>
>>>>>>>>>>>> Il 03/10/2015 00:50, Eric Anholt ha scritto:
>>>>>>>>>>>>> Fabio Fantoni <fabio.fantoni at m2r.biz> writes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi, I want try VC4 on rpi2 with wayland on debian (I used 
>>>>>>>>>>>>>> Sid).
>>>>>>>>>>>>>> Following this howto:
>>>>>>>>>>>>>> http://dri.freedesktop.org/wiki/VC4/
>>>>>>>>>>>>>> I rebuild the kernel from
>>>>>>>>>>>>>> https://github.com/anholt/linux/tree/vc4-kms-v3d-rpi2
>>>>>>>>>>>>>> Base config modified with: CONFIG_DRM_VC4=y and
>>>>>>>>>>>>>> CONFIG_CMA_SIZE_MBYTES=128, full .config in attachment.
>>>>>>>>>>>>>> I did the 2 additions to rpi2 config.txt (full in 
>>>>>>>>>>>>>> attachment).
>>>>>>>>>>>>>> New kernel is working, in kern.log about drm I saw only this
>>>>>>>>>>>>>> about
>>>>>>>>>>>>>> drm:
>>>>>>>>>>>>>> Oct  1 11:11:16 jessie-rpi kernel: [ 1.577017] [drm]
>>>>>>>>>>>>>> Initialized drm
>>>>>>>>>>>>>> 1.1.0 20060810
>>>>>>>>>>>>>> I suppose that compiling with CONFIG_DRM_VC4=y should be
>>>>>>>>>>>>>> present
>>>>>>>>>>>>>> but I
>>>>>>>>>>>>>> not saw line about.
>>>>>>>>>>>>> You should also have various lines in dmesg about:
>>>>>>>>>>>>>
>>>>>>>>>>>>> [    3.185410] vc4-drm soc:vc4 at 7e4c0000: bound 20902000.hdmi
>>>>>>>>>>>>> (ops
>>>>>>>>>>>>> vc4_hdmi_ops)
>>>>>>>>>>>>> [    3.200606] vc4-drm soc:vc4 at 7e4c0000: bound
>>>>>>>>>>>>> 20206000.pixelvalve
>>>>>>>>>>>>> (ops vc4_crtc_ops)
>>>>>>>>>>>>> [    3.220583] vc4-drm soc:vc4 at 7e4c0000: bound
>>>>>>>>>>>>> 20207000.pixelvalve
>>>>>>>>>>>>> (ops vc4_crtc_ops)
>>>>>>>>>>>>> [    3.232884] vc4-drm soc:vc4 at 7e4c0000: bound
>>>>>>>>>>>>> 20807000.pixelvalve
>>>>>>>>>>>>> (ops vc4_crtc_ops)
>>>>>>>>>>>>> [    3.250938] vc4-drm soc:vc4 at 7e4c0000: bound 
>>>>>>>>>>>>> 20400000.hvs (ops
>>>>>>>>>>>>> vc4_hvs_ops)
>>>>>>>>>>>>> [    3.263385] [drm] Supports vblank timestamp caching Rev 2
>>>>>>>>>>>>> (21.10.2013).
>>>>>>>>>>>>> [    3.270162] [drm] No driver support for vblank timestamp
>>>>>>>>>>>>> query.
>>>>>>>>>>>>> [    3.470743] Console: switching to colour frame buffer
>>>>>>>>>>>>> device 240x67
>>>>>>>>>>>>> [    3.540179] vc4-drm soc:vc4 at 7e4c0000: fb0: frame buffer
>>>>>>>>>>>>> device
>>>>>>>>>>>>>
>>>>>>>>>>>>> so something is going wrong and keeping you from probing.
>>>>>>>>>>>>> There's at
>>>>>>>>>>>>> least one problem in your config -- you can't have
>>>>>>>>>>>>>
>>>>>>>>>>>>> CONFIG_FB_BCM2708=y
>>>>>>>>>>>>>
>>>>>>>>>>>>> since you're trying to run a proper graphics driver,
>>>>>>>>>>>>> instead.  I don't
>>>>>>>>>>>>> think that would keep vc4 from probing, though. Maybe you
>>>>>>>>>>>>> wouldn't
>>>>>>>>>>>>> have
>>>>>>>>>>>>> hit any of those "bound" messages because HDMI fails first
>>>>>>>>>>>>> due to your
>>>>>>>>>>>>> config being missing:
>>>>>>>>>>>>>
>>>>>>>>>>>>> CONFIG_I2C_BCM2835=y
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've added that to the wiki page.
>>>>>>>>>>>> Thanks for your reply and all your work.
>>>>>>>>>>>> I recompiled the kernel and retried, now screen show only and
>>>>>>>>>>>> always
>>>>>>>>>>>> "initial image" but system with ssh is working.
>>>>>>>>>>>> Strange thing is that I not found vc4-drm lines also in this
>>>>>>>>>>>> case.
>>>>>>>>>>>> Actual kernel .config and kern.log in attachment.
>>>>>>>>>>>> I did something missed or wrong or there is problem or an
>>>>>>>>>>>> unexpected
>>>>>>>>>>>> case?
>>>>>>>>>>>> I suppose is probable that also kernel parameters may change
>>>>>>>>>>>> something
>>>>>>>>>>>> but I don't know if I must change something, actual 
>>>>>>>>>>>> cmdline.txt.
>>>>>>>>>>>> config.txt already attached in previous mail is ok or other
>>>>>>>>>>>> changes not
>>>>>>>>>>>> present in wiki are present?
>>>>>>>>>>>> I also saw the strange thing that kernel is launched with
>>>>>>>>>>>> addition
>>>>>>>>>>>> parameters (from kern.log) but I not know how and if can be a
>>>>>>>>>>>> problem:
>>>>>>>>>>>>> Oct  3 17:22:02 jessie-rpi kernel: [ 0.000000] Kernel command
>>>>>>>>>>>>> line:
>>>>>>>>>>>>> dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1360
>>>>>>>>>>>>> bcm2708_fb.fbheight=768
>>>>>>>>>>>>> bcm2708.boardrev=0x2000010 bcm2708.serial=0x968d5adc
>>>>>>>>>>>>> smsc95xx.macaddr=B8:27:EB:8D:5A:DC bcm2708_fb.fbswap=1
>>>>>>>>>>>>> bcm2708.disk_led_gpio=47 bcm2708.disk_led_active_low=0
>>>>>>>>>>>>> sdhci-bcm2708.emmc_clock_freq=250000000
>>>>>>>>>>>>> vc_mem.mem_base=0x3dc00000
>>>>>>>>>>>>> vc_mem.mem_size=0x3f000000 dwc_otg.lpm_enable=0
>>>>>>>>>>>>> console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 
>>>>>>>>>>>>> rootwait
>>>>>>>>>>>>> net.ifnames=1
>>>>>>>>>>>> If you need more informations or tests tell me and I'll post
>>>>>>>>>>>> them.
>>>>>>>>>>> Looking through the logs again, I'm not sure what's going on.
>>>>>>>>>>> At this
>>>>>>>>>>> point I think I'd start adding DRM_INFO()s in 
>>>>>>>>>>> vc4_drm_register(),
>>>>>>>>>>> vc4_platform_drm_probe() and vc4_drm_bind() to start bisecting
>>>>>>>>>>> where
>>>>>>>>>>> things are going wrong.
>>>>>>>>>> I saw update on vc4-kms-v3d-rpi2 branch, I build it and tried 
>>>>>>>>>> but I
>>>>>>>>>> had the same result.
>>>>>>>>>>
>>>>>>>>>> I created the .config with:
>>>>>>>>>> make bcm2709_defconfig
>>>>>>>>>> and did the changes of the wiki, full .config used is in
>>>>>>>>>> attachment.
>>>>>>>>>> looking the syslog (see attachment) I not saw vc4 even if
>>>>>>>>>> enabled, I
>>>>>>>>>> suppose there is still something wrong or missed in .config.
>>>>>>>>>>
>>>>>>>>>> Thanks for any reply and sorry for my bad english.
>>>>>>>>>>
>>>>>>>>> I retried with many other changes, in latest kernel build 
>>>>>>>>> (config in
>>>>>>>>> attachment) I was able to boot with screen output working and
>>>>>>>>> something
>>>>>>>>> about vc4 in logs but there are errors about it like:
>>>>>>>>>> Oct 28 11:44:19 jessie-rpi kernel: [ 3.695517] vc4-drm
>>>>>>>>>> soc:gpu at 7e4c0000: failed to bind 3f902000.hdmi (ops
>>>>>>>>>> vc4_hdmi_ops): -517
>>>>>>>>>> Oct 28 11:44:19 jessie-rpi kernel: [ 3.713539] vc4-drm
>>>>>>>>>> soc:gpu at 7e4c0000: master bind failed: -517
>>>>>>>> Those errors are the normal -EPROBE_DEFERs because Linux sucks at
>>>>>>>> device
>>>>>>>> probe ordering.  You get a successful DRM probe a moment later
>>>>>>>> when I2C2
>>>>>>>> probes.
>>>>>>>>
>>>>>>>>> Full syslog in attachment.
>>>>>>>>> I was able to boot weston with vc4 drm but screen output always
>>>>>>>>> freeze
>>>>>>>>> after terminal window draw.
>>>>>>>>>     From log I saw a segfault but trying to take a backtrace 
>>>>>>>>> with gdb
>>>>>>>>> strangely fails, weston log in attachment.
>>>>>>>>>
>>>>>>>>> If you need more informations/tests tell me and I'll post them.
>>>>>>>> Next step is to figure out how to get a good backtrace from gdb.
>>>>>>>>
>>>>>>> I tried to update all debian sid packages and rebuild update mesa
>>>>>>> 11.0.4-1 packages with vc4 with same result.
>>>>>>> With gdbserver connecting to it with ssh I'm able to have gdb 
>>>>>>> working
>>>>>>> until segfault but when I do "bt full" for take the backtrace show
>>>>>>> only
>>>>>>> these kernel messages:
>>>>>>>> Message from syslogd at jessie-rpi at Nov  1 11:18:34 ...
>>>>>>>>    kernel:[  487.628849] Internal error: Oops: 807 [#1] PREEMPT 
>>>>>>>> SMP
>>>>>>>> ARM
>>>>>>>> ...
>>>>>>>>
>>>>>>> I not other way to take a backtrace.
>>>>>>> Can you post your kernel's .config for rpi2 please? I suppose 
>>>>>>> there is
>>>>>>> still something different that cause problem.
>>>>>> I've updated http://dri.freedesktop.org/wiki/VC4/ to have links to
>>>>>> .configs.
>>>>> I rebuilt kernel with your .config and added cma=256M at 512M to
>>>>> cmdline.txt but happen the same problem and I'm still unable to take
>>>>> a backtrace with gdb :(
>>>>>> Message from syslogd at jessie-rpi at Nov 6 14:09:10 ...
>>>>>>   kernel:[  283.621660] Internal error: Oops: 807 [#1] PREEMPT 
>>>>>> SMP ARM
>>>>>> ...
>>>> I rebuilt the kernel adding CONFIG_DEBUG_INFO=y to .config and I
>>>> translated the new trace with addr2line, didn't work for any address
>>>> (I suppose related to other softwares) but probably can be useful see
>>>> the kernel lines called:
>>>>
>>>> kernel:[  798.087325] Internal error: Oops: 807 [#1] PREEMPT SMP ARM
>>>>
>>>> Message from syslogd at jessie-rpi at Nov 12 10:35:37 ...
>>>>   kernel:[  798.164526] Process weston (pid: 616, stack limit =
>>>> 0xb656a210)
>>>>
>>>> Message from syslogd at jessie-rpi at Nov 12 10:35:37 ...
>>>>   kernel:[  798.170443] Stack: (0xb656bba0 to 0xb656c000)
>>>>
>>>> Message from syslogd at jessie-rpi at Nov 12 10:35:37 ...
>>>>   kernel:[  798.174810] bba0: b656bbdc b656bbb0 80482938 80486fe4
>>>> ba1eb800 b6590dc0 00000002 ba375e10
>>>>
>>>> for addr in b656bbdc b656bbb0 80482938 80486fe4 ba1eb800 b6590dc0
>>>> 00000002 ba375e10; do addr2line -e vmlinux -if $addr; done
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> vc4_crtc_atomic_flush
>>>> /root/linux/vc4/drivers/gpu/drm/vc4/vc4_crtc.c:388
>>>> vc4_plane_write_dlist
>>>> /root/linux/vc4/drivers/gpu/drm/vc4/vc4_plane.c:257
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> __vectors_start
>>>> /root/linux/vc4/arch/arm/kernel/entry-armv.S:1221
>>>> ??
>>>> ??:0
>>>>
>>>> Message from syslogd at jessie-rpi at Nov 12 10:35:37 ...
>>>>   kernel:[  798.182990] bbc0: b964c480 80988e30 00000000 b6590dc0
>>>> b656bc04 b656bbe0 8045804c 804828c4
>>>>
>>>> for addr in b964c480 80988e30 00000000 b6590dc0 b656bc04 b656bbe0
>>>> 8045804c 804828c4; do addr2line -e vmlinux -if $addr; done
>>>> ??
>>>> ??:0
>>>> __start_rodata
>>>> .tmp_kallsyms2.o:?
>>>> __vectors_start
>>>> /root/linux/vc4/arch/arm/kernel/entry-armv.S:1221
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> drm_atomic_helper_commit_planes
>>>> /root/linux/vc4/drivers/gpu/drm/drm_atomic_helper.c:1179
>>>> vc4_crtc_atomic_flush
>>>> /root/linux/vc4/drivers/gpu/drm/vc4/vc4_crtc.c:366
>>>>
>>>> Message from syslogd at jessie-rpi at Nov 12 10:35:37 ...
>>>>   kernel:[  798.191169] bbe0: b6590dc0 ba1eb800 b65cd5c0 b985ec10
>>>> b65cd5c0 00000000 b656bc24 b656bc08
>>>>
>>>> for addr in b6590dc0 ba1eb800 b65cd5c0 b985ec10 b65cd5c0 00000000
>>>> b656bc24 b656bc08; do addr2line -e vmlinux -if $addr; done
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> __vectors_start
>>>> /root/linux/vc4/arch/arm/kernel/entry-armv.S:1221
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>>
>>>> Message from syslogd at jessie-rpi at Nov 12 10:35:37 ...
>>>>   kernel:[  798.199349] bc00: 80483be8 80457ebc ffffffff ffffffff
>>>> 00000000 00000000 b656bc64 b656bc28
>>>>
>>>> for addr in 80483be8 80457ebc ffffffff ffffffff 00000000 00000000
>>>> b656bc64 b656bc28; do addr2line -e vmlinux -if $addr; done
>>>> vc4_atomic_complete_commit
>>>> /root/linux/vc4/drivers/gpu/drm/vc4/vc4_kms.c:50
>>>> drm_atomic_helper_commit_planes
>>>> /root/linux/vc4/drivers/gpu/drm/drm_atomic_helper.c:1134
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> __vectors_start
>>>> /root/linux/vc4/arch/arm/kernel/entry-armv.S:1221
>>>> __vectors_start
>>>> /root/linux/vc4/arch/arm/kernel/entry-armv.S:1221
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>>
>>>> Message from syslogd at jessie-rpi at Nov 12 10:35:37 ...
>>>>   kernel:[  798.207529] bc20: 80483d54 80483bb8 ffffffff ffffffff
>>>> 00000000 ba1eb800 b964c380 b6590dc0
>>>>
>>>> for addr in 80483d54 80483bb8 ffffffff ffffffff 00000000 ba1eb800
>>>> b964c380 b6590dc0; do addr2line -e vmlinux -if $addr; done
>>>> vc4_atomic_commit
>>>> /root/linux/vc4/drivers/gpu/drm/vc4/vc4_kms.c:171
>>>> vc4_atomic_complete_commit
>>>> /root/linux/vc4/drivers/gpu/drm/vc4/vc4_kms.c:41
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> __vectors_start
>>>> /root/linux/vc4/arch/arm/kernel/entry-armv.S:1221
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>>
>>>> Message from syslogd at jessie-rpi at Nov 12 10:35:37 ...
>>>>   kernel:[  798.215709] bc40: ba1eb800 b9af8410 b668c900 0000003c
>>>> b964c380 00400000 b656bc7c b656bc68
>>>>
>>>> Message from syslogd at jessie-rpi at Nov 12 10:35:37 ...
>>>>   kernel:[  798.223889] bc60: 8047f848 80483c34 b6590dc0 ba375e10
>>>> b656bcb4 b656bc80 804590d0 8047f800
>>>>
>>>> for addr in 8047f848 80483c34 b6590dc0 ba375e10 b656bcb4 b656bc80
>>>> 804590d0 8047f800; do addr2line -e vmlinux -if $addr; done
>>>> drm_atomic_commit
>>>> /root/linux/vc4/drivers/gpu/drm/drm_atomic.c:1259
>>>> vc4_atomic_commit
>>>> /root/linux/vc4/drivers/gpu/drm/vc4/vc4_kms.c:99
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> ??
>>>> ??:0
>>>> drm_atomic_helper_update_plane
>>>> /root/linux/vc4/drivers/gpu/drm/drm_atomic_helper.c:1400
>>>> drm_atomic_commit
>>>> /root/linux/vc4/drivers/gpu/drm/drm_atomic.c:1248
>>>>
>>>> At the end of kern.log I found this:
>>>> Nov 12 10:35:37 jessie-rpi kernel: [  798.065866] Unable to handle
>>>> kernel paging request at virtual address bb8d6000
>>>> Nov 12 10:35:37 jessie-rpi kernel: [  798.073629] pgd = b871c000
>>>>
>>> I saw this PR where wrote there are a stability improvements:
>>> https://github.com/raspberrypi/linux/pull/1228
>>> I tried the updated kernel and mesa from
>>> https://github.com/anholt/mesa/tree/11.1-vc4 but the same hang problem
>>> still happen :(
>>> What else can I do?
>> That was about 3D, while you're crashing in modesetting somewhere.
>> Generally my approach for this kind of thing is to start decorating the
>> code that's crashing with DRM_INFO()s to find what's going wrong.
>
> WIthout a fulll backtrace I don't have any idea of how to adding good 
> logging on possible unexpected case and probably I don't have enogh 
> knowledge for trying something in the function decode in the kernel 
> call trace.
> Can you doing a fast patch with useful logging that I can try (and 
> post result) please?
>
> Thanks for any reply and sorry for my bad english.

Today I did other tests.
I tried to add  this fix 
https://github.com/anholt/linux/commit/5645e785cea2f33acdc5e5cee62b3ce8a00f1169 
but nothing changed.
I tried latest gohai image (20151220-1053) that use xorg instead but 
also with this hang in few minutes.
Seems strange you are unable to reproduce it.
What is the base system image are you using? (I tried with gohai that is 
based on rasbian jessie and debian sid with software from debian armhf 
repository plus kernel and mesa rebuilt with vc4)
Do you have a base image with working vc4 (even if not debian based) 
uploaded somewhere or that you can upload it please?

Thanks for reply and sorry for my bad english.

More information about the mesa-users mailing list