Re: Testing VC4 on rpi2 with wayland and weston, weston fail to start with drm (trace translated with addr2line included)

Il 17/12/2015 20:01, Eric Anholt ha scritto:
> Fabio Fantoni <[email protected]> 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 <[email protected]> writes:
>>>>>
>>>>>> Il 30/10/2015 18:49, Eric Anholt ha scritto:
>>>>>>> Fabio Fantoni <[email protected]> writes:
>>>>>>>
>>>>>>>> Il 25/10/2015 15:32, Fabio Fantoni ha scritto:
>>>>>>>>> Il 07/10/2015 00:01, Eric Anholt ha scritto:
>>>>>>>>>> Fabio Fantoni <[email protected]> writes:
>>>>>>>>>>
>>>>>>>>>>> Il 03/10/2015 00:50, Eric Anholt ha scritto:
>>>>>>>>>>>> Fabio Fantoni <[email protected]> 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@7e4c0000: bound 20902000.hdmi
>>>>>>>>>>>> (ops
>>>>>>>>>>>> vc4_hdmi_ops)
>>>>>>>>>>>> [    3.200606] vc4-drm soc:vc4@7e4c0000: bound
>>>>>>>>>>>> 20206000.pixelvalve
>>>>>>>>>>>> (ops vc4_crtc_ops)
>>>>>>>>>>>> [    3.220583] vc4-drm soc:vc4@7e4c0000: bound
>>>>>>>>>>>> 20207000.pixelvalve
>>>>>>>>>>>> (ops vc4_crtc_ops)
>>>>>>>>>>>> [    3.232884] vc4-drm soc:vc4@7e4c0000: bound
>>>>>>>>>>>> 20807000.pixelvalve
>>>>>>>>>>>> (ops vc4_crtc_ops)
>>>>>>>>>>>> [    3.250938] vc4-drm soc:vc4@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@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@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@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@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@512M to
>>>> cmdline.txt but happen the same problem and I'm still unable to take
>>>> a backtrace with gdb :(
>>>>> Message from syslogd@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@jessie-rpi at Nov 12 10:35:37 ...
>>>   kernel:[  798.164526] Process weston (pid: 616, stack limit =
>>> 0xb656a210)
>>>
>>> Message from syslogd@jessie-rpi at Nov 12 10:35:37 ...
>>>   kernel:[  798.170443] Stack: (0xb656bba0 to 0xb656c000)
>>>
>>> Message from syslogd@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@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@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@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@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@jessie-rpi at Nov 12 10:35:37 ...
>>>   kernel:[  798.215709] bc40: ba1eb800 b9af8410 b668c900 0000003c
>>> b964c380 00400000 b656bc7c b656bc68
>>>
>>> Message from syslogd@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.
_______________________________________________
mesa-users mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-users