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

Eric Anholt <[email protected]> Thu, 17 Dec 2015 11:01:47 -0800
Newsgroups	gmane.comp.video.mesa3d.user
Message-ID	<[email protected]>
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.

_______________________________________________
mesa-users mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/mesa-users
signature.asc (application/pgp-signature, 818 B)