Re: [BUG] drm/vc4: vblank wait timed out
Hi Boris, > Boris Brezillon hat am 7. Mai 2018 um 09:11 > geschrieben: > > > On Sun, 6 May 2018 01:56:36 +0200 (CEST) > Stefan Wahren wrote: > > > > Boris Brezillon hat am 5. Mai 2018 um 20:00 > > > geschrieben: > > > > > > > > > On Sat, 5 May 2018 19:44:57 +0200 (CEST) > > > Stefan Wahren wrote: > > > > > > > Hi Stefan, > > > > > > > > > Stefan Schake hat am 5. Mai 2018 um 19:29 > > > > > geschrieben: > > > > > > > > > > > > > > > On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren > > > > > wrote: > > > > > > Hi, > > > > > > > > > > > > after submit of the latest bcm2835 clock fixes, i thought this > > > > > > issue has been fixed. But i've seen this issue with current > > > > > > mainline 4.17-rc3 (bcm2835_defconfig) on Raspberry Pi 1 B (using > > > > > > U-Boot TFTP Boot). Strangly i couldn't reproduce this issue with > > > > > > same kernel but using only the Foundation bootloader (without > > > > > > U-Boot TFTP Boot). > > > > > > > > > > > > U-Boot version: 2018.03 > > > > > > > > > > > > I triggered the warning using my HDMI switch: > > > > > > > > > > > > [ 198.304572] [ cut here ] > > > > > > [ 198.304693] WARNING: CPU: 0 PID: 10 at > > > > > > drivers/gpu/drm/drm_atomic_helper.c:1351 > > > > > > drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0 [ 198.304703] > > > > > > [CRTC:68:crtc-2] vblank wait timed out [ 198.304751] Modules > > > > > > linked in: bcm2835_rng rng_core vchiq(C) [ 198.304790] CPU: 0 > > > > > > PID: 10 Comm: kworker/0:1 Tainted: G C4.17.0-rc3+ > > > > > > #1 [ 198.304796] Hardware name: BCM2835 [ 198.304817] > > > > > > Workqueue: events output_poll_execute [ 198.304867] [] > > > > > > (unwind_backtrace) from [] (show_stack+0x20/0x24) > > > > > > [ 198.304934] [] (show_stack) from [] > > > > > > (dump_stack+0x20/0x28) [ 198.304971] [] (dump_stack) > > > > > > from [] (__warn+0xec/0x104) [ 198.305012] [] > > > > > > (__warn) from [] (warn_slowpath_fmt+0x48/0x50) > > > > > > [ 198.305048] [] (warn_slowpath_fmt) from [] > > > > > > (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] > > > > > > [] (drm_atomic_helper_wait_for_vblanks) from > > > > > > [] (vc4_atomic_complete_commit+0x80/0xb8) > > > > > > [ 198.305144] [] (vc4_atomic_complete_commit) from > > > > > > [] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] > > > > > > [] (vc4_atomic_commit) from [] > > > > > > (drm_atomic_commit+0x50/0x60) [ 198.305202] [] > > > > > > (drm_atomic_commit) from [] > > > > > > (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] > > > > > > [] (restore_fbdev_mode_atomic) from [] > > > > > > (restore_fbdev_mode+0x38/0x144) [ 198.305270] [] > > > > > > (restore_fbdev_mode) from [] > > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) > > > > > > [ 198.305296] [] > > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > > > > > > (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [] > > > > > > (drm_fb_helper_set_par) from [] > > > > > > (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] > > > > > > [] (drm_fb_helper_hotplug_event) from [] > > > > > > (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] > > > > > > [] (drm_fb_helper_output_poll_changed) from > > > > > > [] (drm_kms_helper_hotplug_event+0x34/0x38) > > > > > > [ 198.305409] [] (drm_kms_helper_hotplug_event) from > > > > > > [] (output_poll_execute+0x16c/0x17c) [ 198.305440] > > > > > > [] (output_poll_execute) from [] > > > > > > (process_one_work+0x1e0/0x368) [ 198.305466] [] > > > > > > (process_one_work) from [] (worker_thread+0x2a0/0x418) > > > > > > [ 198.305511] [] (worker_thread) from [] > > > > > > (kthread+0x144/0x15c) [ 198.305539] [] (kthread) from > > > > > > [] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception > > > > > > stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] > > > > > > 9fa0: > > > > > > [ 198.305578] 9fc0: > > > > > > [ 198.305591] 9fe0: > > > > > > 0013 > > > > > > [ 198.305630] ---[ end trace 9c4071c657268b83 ]--- > > > > > > > > > > > > I also dumped clk_summary in both cases, but they were identical. > > > > > > > > > > > > Are their any helpful information, which i can provide? > > > > > > > > > > > > Best regards > > > > > > Stefan > > > > > > > > > > I have seen this happen with one of those cheap Waveshare HDMI > > > > > displays. More often when connecting its power to the RPi versus on > > > > > a separate supply. Goes away when using a real, proper HDMI > > > > > display. They come with bad EDID data so I pretty much just blamed > > > > > the display at the time. > > > > > > > > > > Does this happen during a switch and whats on the other end? > > > > > > > > The issue happens only in combination with U-Boot. If i switch the > > > > source between my PC and the RPi then so
Re: [BUG] drm/vc4: vblank wait timed out
On Sun, 6 May 2018 01:56:36 +0200 (CEST) Stefan Wahren wrote: > > Boris Brezillon hat am 5. Mai 2018 um 20:00 > > geschrieben: > > > > > > On Sat, 5 May 2018 19:44:57 +0200 (CEST) > > Stefan Wahren wrote: > > > > > Hi Stefan, > > > > > > > Stefan Schake hat am 5. Mai 2018 um 19:29 > > > > geschrieben: > > > > > > > > > > > > On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren > > > > wrote: > > > > > Hi, > > > > > > > > > > after submit of the latest bcm2835 clock fixes, i thought this > > > > > issue has been fixed. But i've seen this issue with current > > > > > mainline 4.17-rc3 (bcm2835_defconfig) on Raspberry Pi 1 B (using > > > > > U-Boot TFTP Boot). Strangly i couldn't reproduce this issue with > > > > > same kernel but using only the Foundation bootloader (without > > > > > U-Boot TFTP Boot). > > > > > > > > > > U-Boot version: 2018.03 > > > > > > > > > > I triggered the warning using my HDMI switch: > > > > > > > > > > [ 198.304572] [ cut here ] > > > > > [ 198.304693] WARNING: CPU: 0 PID: 10 at > > > > > drivers/gpu/drm/drm_atomic_helper.c:1351 > > > > > drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0 [ 198.304703] > > > > > [CRTC:68:crtc-2] vblank wait timed out [ 198.304751] Modules > > > > > linked in: bcm2835_rng rng_core vchiq(C) [ 198.304790] CPU: 0 > > > > > PID: 10 Comm: kworker/0:1 Tainted: G C4.17.0-rc3+ > > > > > #1 [ 198.304796] Hardware name: BCM2835 [ 198.304817] > > > > > Workqueue: events output_poll_execute [ 198.304867] [] > > > > > (unwind_backtrace) from [] (show_stack+0x20/0x24) > > > > > [ 198.304934] [] (show_stack) from [] > > > > > (dump_stack+0x20/0x28) [ 198.304971] [] (dump_stack) > > > > > from [] (__warn+0xec/0x104) [ 198.305012] [] > > > > > (__warn) from [] (warn_slowpath_fmt+0x48/0x50) > > > > > [ 198.305048] [] (warn_slowpath_fmt) from [] > > > > > (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] > > > > > [] (drm_atomic_helper_wait_for_vblanks) from > > > > > [] (vc4_atomic_complete_commit+0x80/0xb8) > > > > > [ 198.305144] [] (vc4_atomic_complete_commit) from > > > > > [] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] > > > > > [] (vc4_atomic_commit) from [] > > > > > (drm_atomic_commit+0x50/0x60) [ 198.305202] [] > > > > > (drm_atomic_commit) from [] > > > > > (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] > > > > > [] (restore_fbdev_mode_atomic) from [] > > > > > (restore_fbdev_mode+0x38/0x144) [ 198.305270] [] > > > > > (restore_fbdev_mode) from [] > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) > > > > > [ 198.305296] [] > > > > > (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > > > > > (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [] > > > > > (drm_fb_helper_set_par) from [] > > > > > (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] > > > > > [] (drm_fb_helper_hotplug_event) from [] > > > > > (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] > > > > > [] (drm_fb_helper_output_poll_changed) from > > > > > [] (drm_kms_helper_hotplug_event+0x34/0x38) > > > > > [ 198.305409] [] (drm_kms_helper_hotplug_event) from > > > > > [] (output_poll_execute+0x16c/0x17c) [ 198.305440] > > > > > [] (output_poll_execute) from [] > > > > > (process_one_work+0x1e0/0x368) [ 198.305466] [] > > > > > (process_one_work) from [] (worker_thread+0x2a0/0x418) > > > > > [ 198.305511] [] (worker_thread) from [] > > > > > (kthread+0x144/0x15c) [ 198.305539] [] (kthread) from > > > > > [] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception > > > > > stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] > > > > > 9fa0: > > > > > [ 198.305578] 9fc0: > > > > > [ 198.305591] 9fe0: > > > > > 0013 > > > > > [ 198.305630] ---[ end trace 9c4071c657268b83 ]--- > > > > > > > > > > I also dumped clk_summary in both cases, but they were identical. > > > > > > > > > > Are their any helpful information, which i can provide? > > > > > > > > > > Best regards > > > > > Stefan > > > > > > > > I have seen this happen with one of those cheap Waveshare HDMI > > > > displays. More often when connecting its power to the RPi versus on > > > > a separate supply. Goes away when using a real, proper HDMI > > > > display. They come with bad EDID data so I pretty much just blamed > > > > the display at the time. > > > > > > > > Does this happen during a switch and whats on the other end? > > > > > > The issue happens only in combination with U-Boot. If i switch the > > > source between my PC and the RPi then sometimes the warning is > > > triggered. Okay, can you dump HDMI and clk regs in both situations (u-boot and the Foundation bootloader)? There's probably a slight difference that makes it work in one case and not the other. ___ dri-dev
Re: [BUG] drm/vc4: vblank wait timed out
> Boris Brezillon hat am 5. Mai 2018 um 20:00 > geschrieben: > > > On Sat, 5 May 2018 19:44:57 +0200 (CEST) > Stefan Wahren wrote: > > > Hi Stefan, > > > > > Stefan Schake hat am 5. Mai 2018 um 19:29 > > > geschrieben: > > > > > > > > > On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren > > > wrote: > > > > Hi, > > > > > > > > after submit of the latest bcm2835 clock fixes, i thought this > > > > issue has been fixed. But i've seen this issue with current > > > > mainline 4.17-rc3 (bcm2835_defconfig) on Raspberry Pi 1 B (using > > > > U-Boot TFTP Boot). Strangly i couldn't reproduce this issue with > > > > same kernel but using only the Foundation bootloader (without > > > > U-Boot TFTP Boot). > > > > > > > > U-Boot version: 2018.03 > > > > > > > > I triggered the warning using my HDMI switch: > > > > > > > > [ 198.304572] [ cut here ] > > > > [ 198.304693] WARNING: CPU: 0 PID: 10 at > > > > drivers/gpu/drm/drm_atomic_helper.c:1351 > > > > drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0 [ 198.304703] > > > > [CRTC:68:crtc-2] vblank wait timed out [ 198.304751] Modules > > > > linked in: bcm2835_rng rng_core vchiq(C) [ 198.304790] CPU: 0 > > > > PID: 10 Comm: kworker/0:1 Tainted: G C4.17.0-rc3+ > > > > #1 [ 198.304796] Hardware name: BCM2835 [ 198.304817] > > > > Workqueue: events output_poll_execute [ 198.304867] [] > > > > (unwind_backtrace) from [] (show_stack+0x20/0x24) > > > > [ 198.304934] [] (show_stack) from [] > > > > (dump_stack+0x20/0x28) [ 198.304971] [] (dump_stack) > > > > from [] (__warn+0xec/0x104) [ 198.305012] [] > > > > (__warn) from [] (warn_slowpath_fmt+0x48/0x50) > > > > [ 198.305048] [] (warn_slowpath_fmt) from [] > > > > (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] > > > > [] (drm_atomic_helper_wait_for_vblanks) from > > > > [] (vc4_atomic_complete_commit+0x80/0xb8) > > > > [ 198.305144] [] (vc4_atomic_complete_commit) from > > > > [] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] > > > > [] (vc4_atomic_commit) from [] > > > > (drm_atomic_commit+0x50/0x60) [ 198.305202] [] > > > > (drm_atomic_commit) from [] > > > > (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] > > > > [] (restore_fbdev_mode_atomic) from [] > > > > (restore_fbdev_mode+0x38/0x144) [ 198.305270] [] > > > > (restore_fbdev_mode) from [] > > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) > > > > [ 198.305296] [] > > > > (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > > > > (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [] > > > > (drm_fb_helper_set_par) from [] > > > > (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] > > > > [] (drm_fb_helper_hotplug_event) from [] > > > > (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] > > > > [] (drm_fb_helper_output_poll_changed) from > > > > [] (drm_kms_helper_hotplug_event+0x34/0x38) > > > > [ 198.305409] [] (drm_kms_helper_hotplug_event) from > > > > [] (output_poll_execute+0x16c/0x17c) [ 198.305440] > > > > [] (output_poll_execute) from [] > > > > (process_one_work+0x1e0/0x368) [ 198.305466] [] > > > > (process_one_work) from [] (worker_thread+0x2a0/0x418) > > > > [ 198.305511] [] (worker_thread) from [] > > > > (kthread+0x144/0x15c) [ 198.305539] [] (kthread) from > > > > [] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception > > > > stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] > > > > 9fa0: > > > > [ 198.305578] 9fc0: > > > > [ 198.305591] 9fe0: > > > > 0013 > > > > [ 198.305630] ---[ end trace 9c4071c657268b83 ]--- > > > > > > > > I also dumped clk_summary in both cases, but they were identical. > > > > > > > > Are their any helpful information, which i can provide? > > > > > > > > Best regards > > > > Stefan > > > > > > I have seen this happen with one of those cheap Waveshare HDMI > > > displays. More often when connecting its power to the RPi versus on > > > a separate supply. Goes away when using a real, proper HDMI > > > display. They come with bad EDID data so I pretty much just blamed > > > the display at the time. > > > > > > Does this happen during a switch and whats on the other end? > > > > The issue happens only in combination with U-Boot. If i switch the > > source between my PC and the RPi then sometimes the warning is > > triggered. > > Is it working despite the WARN backtrace, or do you then get a black > screen? It always works, but sometimes the screen stays a little bit (~ 6 secs) longer black before the console appears. > You say sometimes, that means sometimes it works, right? It works always, the sometimes refers to the warning. > Also, > do you remember the mode (resolution+refresh-rate) you're using? 1920 x 1080 @ 60 Hz ___ dri-devel mailing list dri-devel@lists.freedeskto
[BUG] drm/vc4: vblank wait timed out
Hi, after submit of the latest bcm2835 clock fixes, i thought this issue has been fixed. But i've seen this issue with current mainline 4.17-rc3 (bcm2835_defconfig) on Raspberry Pi 1 B (using U-Boot TFTP Boot). Strangly i couldn't reproduce this issue with same kernel but using only the Foundation bootloader (without U-Boot TFTP Boot). U-Boot version: 2018.03 I triggered the warning using my HDMI switch: [ 198.304572] [ cut here ] [ 198.304693] WARNING: CPU: 0 PID: 10 at drivers/gpu/drm/drm_atomic_helper.c:1351 drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0 [ 198.304703] [CRTC:68:crtc-2] vblank wait timed out [ 198.304751] Modules linked in: bcm2835_rng rng_core vchiq(C) [ 198.304790] CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G C 4.17.0-rc3+ #1 [ 198.304796] Hardware name: BCM2835 [ 198.304817] Workqueue: events output_poll_execute [ 198.304867] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [ 198.304934] [] (show_stack) from [] (dump_stack+0x20/0x28) [ 198.304971] [] (dump_stack) from [] (__warn+0xec/0x104) [ 198.305012] [] (__warn) from [] (warn_slowpath_fmt+0x48/0x50) [ 198.305048] [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] [] (drm_atomic_helper_wait_for_vblanks) from [] (vc4_atomic_complete_commit+0x80/0xb8) [ 198.305144] [] (vc4_atomic_complete_commit) from [] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] [] (vc4_atomic_commit) from [] (drm_atomic_commit+0x50/0x60) [ 198.305202] [] (drm_atomic_commit) from [] (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] [] (restore_fbdev_mode_atomic) from [] (restore_fbdev_mode+0x38/0x144) [ 198.305270] [] (restore_fbdev_mode) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) [ 198.305296] [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [] (drm_fb_helper_set_par) from [] (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] [] (drm_fb_helper_hotplug_event) from [] (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] [] (drm_fb_helper_output_poll_changed) from [] (drm_kms_helper_hotplug_event+0x34/0x38) [ 198.305409] [] (drm_kms_helper_hotplug_event) from [] (output_poll_execute+0x16c/0x17c) [ 198.305440] [] (output_poll_execute) from [] (process_one_work+0x1e0/0x368) [ 198.305466] [] (process_one_work) from [] (worker_thread+0x2a0/0x418) [ 198.305511] [] (worker_thread) from [] (kthread+0x144/0x15c) [ 198.305539] [] (kthread) from [] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] 9fa0: [ 198.305578] 9fc0: [ 198.305591] 9fe0: 0013 [ 198.305630] ---[ end trace 9c4071c657268b83 ]--- I also dumped clk_summary in both cases, but they were identical. Are their any helpful information, which i can provide? Best regards Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] drm/vc4: vblank wait timed out
Hi Stefan, > Stefan Schake hat am 5. Mai 2018 um 19:29 geschrieben: > > > On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren wrote: > > Hi, > > > > after submit of the latest bcm2835 clock fixes, i thought this issue has > > been fixed. But i've seen this issue with current mainline 4.17-rc3 > > (bcm2835_defconfig) on Raspberry Pi 1 B (using U-Boot TFTP Boot). Strangly > > i couldn't reproduce this issue with same kernel but using only the > > Foundation bootloader (without U-Boot TFTP Boot). > > > > U-Boot version: 2018.03 > > > > I triggered the warning using my HDMI switch: > > > > [ 198.304572] [ cut here ] > > [ 198.304693] WARNING: CPU: 0 PID: 10 at > > drivers/gpu/drm/drm_atomic_helper.c:1351 > > drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0 > > [ 198.304703] [CRTC:68:crtc-2] vblank wait timed out > > [ 198.304751] Modules linked in: bcm2835_rng rng_core vchiq(C) > > [ 198.304790] CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G C > > 4.17.0-rc3+ #1 > > [ 198.304796] Hardware name: BCM2835 > > [ 198.304817] Workqueue: events output_poll_execute > > [ 198.304867] [] (unwind_backtrace) from [] > > (show_stack+0x20/0x24) > > [ 198.304934] [] (show_stack) from [] > > (dump_stack+0x20/0x28) > > [ 198.304971] [] (dump_stack) from [] > > (__warn+0xec/0x104) > > [ 198.305012] [] (__warn) from [] > > (warn_slowpath_fmt+0x48/0x50) > > [ 198.305048] [] (warn_slowpath_fmt) from [] > > (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) > > [ 198.305098] [] (drm_atomic_helper_wait_for_vblanks) from > > [] (vc4_atomic_complete_commit+0x80/0xb8) > > [ 198.305144] [] (vc4_atomic_complete_commit) from [] > > (vc4_atomic_commit+0x110/0x11c) > > [ 198.305174] [] (vc4_atomic_commit) from [] > > (drm_atomic_commit+0x50/0x60) > > [ 198.305202] [] (drm_atomic_commit) from [] > > (restore_fbdev_mode_atomic+0x80/0x1cc) > > [ 198.305228] [] (restore_fbdev_mode_atomic) from [] > > (restore_fbdev_mode+0x38/0x144) > > [ 198.305270] [] (restore_fbdev_mode) from [] > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) > > [ 198.305296] [] (drm_fb_helper_restore_fbdev_mode_unlocked) > > from [] (drm_fb_helper_set_par+0x54/0x60) > > [ 198.305320] [] (drm_fb_helper_set_par) from [] > > (drm_fb_helper_hotplug_event+0xc8/0xd4) > > [ 198.305343] [] (drm_fb_helper_hotplug_event) from [] > > (drm_fb_helper_output_poll_changed+0x1c/0x20) > > [ 198.305382] [] (drm_fb_helper_output_poll_changed) from > > [] (drm_kms_helper_hotplug_event+0x34/0x38) > > [ 198.305409] [] (drm_kms_helper_hotplug_event) from > > [] (output_poll_execute+0x16c/0x17c) > > [ 198.305440] [] (output_poll_execute) from [] > > (process_one_work+0x1e0/0x368) > > [ 198.305466] [] (process_one_work) from [] > > (worker_thread+0x2a0/0x418) > > [ 198.305511] [] (worker_thread) from [] > > (kthread+0x144/0x15c) > > [ 198.305539] [] (kthread) from [] > > (ret_from_fork+0x14/0x2c) > > [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) > > [ 198.305562] 9fa0: > > > > [ 198.305578] 9fc0: > > > > [ 198.305591] 9fe0: 0013 > > [ 198.305630] ---[ end trace 9c4071c657268b83 ]--- > > > > I also dumped clk_summary in both cases, but they were identical. > > > > Are their any helpful information, which i can provide? > > > > Best regards > > Stefan > > I have seen this happen with one of those cheap Waveshare HDMI displays. > More often when connecting its power to the RPi versus on a separate > supply. Goes away when using a real, proper HDMI display. They come with > bad EDID data so I pretty much just blamed the display at the time. > > Does this happen during a switch and whats on the other end? The issue happens only in combination with U-Boot. If i switch the source between my PC and the RPi then sometimes the warning is triggered. VPU firmware: 2018-04-16 Display: HP ZR2440w > > Thanks, > Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] drm/vc4: vblank wait timed out
Hi Boris, > Boris Brezillon hat am 5. Mai 2018 um 14:24 > geschrieben: > > > On Sat, 5 May 2018 13:47:25 +0200 (CEST) > Stefan Wahren wrote: > > > Hi, > > > > after submit of the latest bcm2835 clock fixes, i thought this issue has > > been fixed. But i've seen this issue with current mainline 4.17-rc3 > > (bcm2835_defconfig) on Raspberry Pi 1 B (using U-Boot TFTP Boot). Strangly > > i couldn't reproduce this issue with same kernel but using only the > > Foundation bootloader (without U-Boot TFTP Boot). > > > > U-Boot version: 2018.03 > > > > I triggered the warning using my HDMI switch: > > > > [ 198.304572] [ cut here ] > > [ 198.304693] WARNING: CPU: 0 PID: 10 at > > drivers/gpu/drm/drm_atomic_helper.c:1351 > > drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0 > > [ 198.304703] [CRTC:68:crtc-2] vblank wait timed out > > [ 198.304751] Modules linked in: bcm2835_rng rng_core vchiq(C) > > [ 198.304790] CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G C > > 4.17.0-rc3+ #1 > > [ 198.304796] Hardware name: BCM2835 > > [ 198.304817] Workqueue: events output_poll_execute > > [ 198.304867] [] (unwind_backtrace) from [] > > (show_stack+0x20/0x24) > > [ 198.304934] [] (show_stack) from [] > > (dump_stack+0x20/0x28) > > [ 198.304971] [] (dump_stack) from [] > > (__warn+0xec/0x104) > > [ 198.305012] [] (__warn) from [] > > (warn_slowpath_fmt+0x48/0x50) > > [ 198.305048] [] (warn_slowpath_fmt) from [] > > (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) > > [ 198.305098] [] (drm_atomic_helper_wait_for_vblanks) from > > [] (vc4_atomic_complete_commit+0x80/0xb8) > > [ 198.305144] [] (vc4_atomic_complete_commit) from [] > > (vc4_atomic_commit+0x110/0x11c) > > [ 198.305174] [] (vc4_atomic_commit) from [] > > (drm_atomic_commit+0x50/0x60) > > [ 198.305202] [] (drm_atomic_commit) from [] > > (restore_fbdev_mode_atomic+0x80/0x1cc) > > [ 198.305228] [] (restore_fbdev_mode_atomic) from [] > > (restore_fbdev_mode+0x38/0x144) > > [ 198.305270] [] (restore_fbdev_mode) from [] > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) > > [ 198.305296] [] (drm_fb_helper_restore_fbdev_mode_unlocked) > > from [] (drm_fb_helper_set_par+0x54/0x60) > > [ 198.305320] [] (drm_fb_helper_set_par) from [] > > (drm_fb_helper_hotplug_event+0xc8/0xd4) > > [ 198.305343] [] (drm_fb_helper_hotplug_event) from [] > > (drm_fb_helper_output_poll_changed+0x1c/0x20) > > [ 198.305382] [] (drm_fb_helper_output_poll_changed) from > > [] (drm_kms_helper_hotplug_event+0x34/0x38) > > [ 198.305409] [] (drm_kms_helper_hotplug_event) from > > [] (output_poll_execute+0x16c/0x17c) > > [ 198.305440] [] (output_poll_execute) from [] > > (process_one_work+0x1e0/0x368) > > [ 198.305466] [] (process_one_work) from [] > > (worker_thread+0x2a0/0x418) > > [ 198.305511] [] (worker_thread) from [] > > (kthread+0x144/0x15c) > > [ 198.305539] [] (kthread) from [] > > (ret_from_fork+0x14/0x2c) > > [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) > > [ 198.305562] 9fa0: > > > > [ 198.305578] 9fc0: > > > > [ 198.305591] 9fe0: 0013 > > [ 198.305630] ---[ end trace 9c4071c657268b83 ]--- > > > > I also dumped clk_summary in both cases, but they were identical. > > > > Are their any helpful information, which i can provide? > > I doubt this will fix your problem, but can you try with this patch > [1] applied? Unfortunately the issue still persists with patch applied. > > Also, is u-boot touching PLLH or anything related to HDMI? Since u-boot needs to enable USB and a console via HDMI this is possible. But this is done via mailbox to the VideoCore firmware, so i can't provide any helpful information [1]. Compared the sysfs regdumps for the following clocks, but didn't see any difference: vpu pllh pllh_pix_prediv Thanks Stefan [1] - https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-bcm283x/msg.c > > [1]https://patchwork.kernel.org/patch/10207159/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] drm/vc4: vblank wait timed out
On Sat, 5 May 2018 19:44:57 +0200 (CEST) Stefan Wahren wrote: > Hi Stefan, > > > Stefan Schake hat am 5. Mai 2018 um 19:29 > > geschrieben: > > > > > > On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren > > wrote: > > > Hi, > > > > > > after submit of the latest bcm2835 clock fixes, i thought this > > > issue has been fixed. But i've seen this issue with current > > > mainline 4.17-rc3 (bcm2835_defconfig) on Raspberry Pi 1 B (using > > > U-Boot TFTP Boot). Strangly i couldn't reproduce this issue with > > > same kernel but using only the Foundation bootloader (without > > > U-Boot TFTP Boot). > > > > > > U-Boot version: 2018.03 > > > > > > I triggered the warning using my HDMI switch: > > > > > > [ 198.304572] [ cut here ] > > > [ 198.304693] WARNING: CPU: 0 PID: 10 at > > > drivers/gpu/drm/drm_atomic_helper.c:1351 > > > drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0 [ 198.304703] > > > [CRTC:68:crtc-2] vblank wait timed out [ 198.304751] Modules > > > linked in: bcm2835_rng rng_core vchiq(C) [ 198.304790] CPU: 0 > > > PID: 10 Comm: kworker/0:1 Tainted: G C4.17.0-rc3+ > > > #1 [ 198.304796] Hardware name: BCM2835 [ 198.304817] > > > Workqueue: events output_poll_execute [ 198.304867] [] > > > (unwind_backtrace) from [] (show_stack+0x20/0x24) > > > [ 198.304934] [] (show_stack) from [] > > > (dump_stack+0x20/0x28) [ 198.304971] [] (dump_stack) > > > from [] (__warn+0xec/0x104) [ 198.305012] [] > > > (__warn) from [] (warn_slowpath_fmt+0x48/0x50) > > > [ 198.305048] [] (warn_slowpath_fmt) from [] > > > (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] > > > [] (drm_atomic_helper_wait_for_vblanks) from > > > [] (vc4_atomic_complete_commit+0x80/0xb8) > > > [ 198.305144] [] (vc4_atomic_complete_commit) from > > > [] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] > > > [] (vc4_atomic_commit) from [] > > > (drm_atomic_commit+0x50/0x60) [ 198.305202] [] > > > (drm_atomic_commit) from [] > > > (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] > > > [] (restore_fbdev_mode_atomic) from [] > > > (restore_fbdev_mode+0x38/0x144) [ 198.305270] [] > > > (restore_fbdev_mode) from [] > > > (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) > > > [ 198.305296] [] > > > (drm_fb_helper_restore_fbdev_mode_unlocked) from [] > > > (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [] > > > (drm_fb_helper_set_par) from [] > > > (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] > > > [] (drm_fb_helper_hotplug_event) from [] > > > (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] > > > [] (drm_fb_helper_output_poll_changed) from > > > [] (drm_kms_helper_hotplug_event+0x34/0x38) > > > [ 198.305409] [] (drm_kms_helper_hotplug_event) from > > > [] (output_poll_execute+0x16c/0x17c) [ 198.305440] > > > [] (output_poll_execute) from [] > > > (process_one_work+0x1e0/0x368) [ 198.305466] [] > > > (process_one_work) from [] (worker_thread+0x2a0/0x418) > > > [ 198.305511] [] (worker_thread) from [] > > > (kthread+0x144/0x15c) [ 198.305539] [] (kthread) from > > > [] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception > > > stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] > > > 9fa0: > > > [ 198.305578] 9fc0: > > > [ 198.305591] 9fe0: > > > 0013 > > > [ 198.305630] ---[ end trace 9c4071c657268b83 ]--- > > > > > > I also dumped clk_summary in both cases, but they were identical. > > > > > > Are their any helpful information, which i can provide? > > > > > > Best regards > > > Stefan > > > > I have seen this happen with one of those cheap Waveshare HDMI > > displays. More often when connecting its power to the RPi versus on > > a separate supply. Goes away when using a real, proper HDMI > > display. They come with bad EDID data so I pretty much just blamed > > the display at the time. > > > > Does this happen during a switch and whats on the other end? > > The issue happens only in combination with U-Boot. If i switch the > source between my PC and the RPi then sometimes the warning is > triggered. Is it working despite the WARN backtrace, or do you then get a black screen? You say sometimes, that means sometimes it works, right? Also, do you remember the mode (resolution+refresh-rate) you're using? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] drm/vc4: vblank wait timed out
On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren wrote: > Hi, > > after submit of the latest bcm2835 clock fixes, i thought this issue has been > fixed. But i've seen this issue with current mainline 4.17-rc3 > (bcm2835_defconfig) on Raspberry Pi 1 B (using U-Boot TFTP Boot). Strangly i > couldn't reproduce this issue with same kernel but using only the Foundation > bootloader (without U-Boot TFTP Boot). > > U-Boot version: 2018.03 > > I triggered the warning using my HDMI switch: > > [ 198.304572] [ cut here ] > [ 198.304693] WARNING: CPU: 0 PID: 10 at > drivers/gpu/drm/drm_atomic_helper.c:1351 > drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0 > [ 198.304703] [CRTC:68:crtc-2] vblank wait timed out > [ 198.304751] Modules linked in: bcm2835_rng rng_core vchiq(C) > [ 198.304790] CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G C > 4.17.0-rc3+ #1 > [ 198.304796] Hardware name: BCM2835 > [ 198.304817] Workqueue: events output_poll_execute > [ 198.304867] [] (unwind_backtrace) from [] > (show_stack+0x20/0x24) > [ 198.304934] [] (show_stack) from [] > (dump_stack+0x20/0x28) > [ 198.304971] [] (dump_stack) from [] (__warn+0xec/0x104) > [ 198.305012] [] (__warn) from [] > (warn_slowpath_fmt+0x48/0x50) > [ 198.305048] [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) > [ 198.305098] [] (drm_atomic_helper_wait_for_vblanks) from > [] (vc4_atomic_complete_commit+0x80/0xb8) > [ 198.305144] [] (vc4_atomic_complete_commit) from [] > (vc4_atomic_commit+0x110/0x11c) > [ 198.305174] [] (vc4_atomic_commit) from [] > (drm_atomic_commit+0x50/0x60) > [ 198.305202] [] (drm_atomic_commit) from [] > (restore_fbdev_mode_atomic+0x80/0x1cc) > [ 198.305228] [] (restore_fbdev_mode_atomic) from [] > (restore_fbdev_mode+0x38/0x144) > [ 198.305270] [] (restore_fbdev_mode) from [] > (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) > [ 198.305296] [] (drm_fb_helper_restore_fbdev_mode_unlocked) from > [] (drm_fb_helper_set_par+0x54/0x60) > [ 198.305320] [] (drm_fb_helper_set_par) from [] > (drm_fb_helper_hotplug_event+0xc8/0xd4) > [ 198.305343] [] (drm_fb_helper_hotplug_event) from [] > (drm_fb_helper_output_poll_changed+0x1c/0x20) > [ 198.305382] [] (drm_fb_helper_output_poll_changed) from > [] (drm_kms_helper_hotplug_event+0x34/0x38) > [ 198.305409] [] (drm_kms_helper_hotplug_event) from [] > (output_poll_execute+0x16c/0x17c) > [ 198.305440] [] (output_poll_execute) from [] > (process_one_work+0x1e0/0x368) > [ 198.305466] [] (process_one_work) from [] > (worker_thread+0x2a0/0x418) > [ 198.305511] [] (worker_thread) from [] > (kthread+0x144/0x15c) > [ 198.305539] [] (kthread) from [] > (ret_from_fork+0x14/0x2c) > [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) > [ 198.305562] 9fa0: > > [ 198.305578] 9fc0: > > [ 198.305591] 9fe0: 0013 > [ 198.305630] ---[ end trace 9c4071c657268b83 ]--- > > I also dumped clk_summary in both cases, but they were identical. > > Are their any helpful information, which i can provide? > > Best regards > Stefan I have seen this happen with one of those cheap Waveshare HDMI displays. More often when connecting its power to the RPi versus on a separate supply. Goes away when using a real, proper HDMI display. They come with bad EDID data so I pretty much just blamed the display at the time. Does this happen during a switch and whats on the other end? Thanks, Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [BUG] drm/vc4: vblank wait timed out
On Sat, 5 May 2018 13:47:25 +0200 (CEST) Stefan Wahren wrote: > Hi, > > after submit of the latest bcm2835 clock fixes, i thought this issue has been > fixed. But i've seen this issue with current mainline 4.17-rc3 > (bcm2835_defconfig) on Raspberry Pi 1 B (using U-Boot TFTP Boot). Strangly i > couldn't reproduce this issue with same kernel but using only the Foundation > bootloader (without U-Boot TFTP Boot). > > U-Boot version: 2018.03 > > I triggered the warning using my HDMI switch: > > [ 198.304572] [ cut here ] > [ 198.304693] WARNING: CPU: 0 PID: 10 at > drivers/gpu/drm/drm_atomic_helper.c:1351 > drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0 > [ 198.304703] [CRTC:68:crtc-2] vblank wait timed out > [ 198.304751] Modules linked in: bcm2835_rng rng_core vchiq(C) > [ 198.304790] CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G C > 4.17.0-rc3+ #1 > [ 198.304796] Hardware name: BCM2835 > [ 198.304817] Workqueue: events output_poll_execute > [ 198.304867] [] (unwind_backtrace) from [] > (show_stack+0x20/0x24) > [ 198.304934] [] (show_stack) from [] > (dump_stack+0x20/0x28) > [ 198.304971] [] (dump_stack) from [] (__warn+0xec/0x104) > [ 198.305012] [] (__warn) from [] > (warn_slowpath_fmt+0x48/0x50) > [ 198.305048] [] (warn_slowpath_fmt) from [] > (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) > [ 198.305098] [] (drm_atomic_helper_wait_for_vblanks) from > [] (vc4_atomic_complete_commit+0x80/0xb8) > [ 198.305144] [] (vc4_atomic_complete_commit) from [] > (vc4_atomic_commit+0x110/0x11c) > [ 198.305174] [] (vc4_atomic_commit) from [] > (drm_atomic_commit+0x50/0x60) > [ 198.305202] [] (drm_atomic_commit) from [] > (restore_fbdev_mode_atomic+0x80/0x1cc) > [ 198.305228] [] (restore_fbdev_mode_atomic) from [] > (restore_fbdev_mode+0x38/0x144) > [ 198.305270] [] (restore_fbdev_mode) from [] > (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) > [ 198.305296] [] (drm_fb_helper_restore_fbdev_mode_unlocked) from > [] (drm_fb_helper_set_par+0x54/0x60) > [ 198.305320] [] (drm_fb_helper_set_par) from [] > (drm_fb_helper_hotplug_event+0xc8/0xd4) > [ 198.305343] [] (drm_fb_helper_hotplug_event) from [] > (drm_fb_helper_output_poll_changed+0x1c/0x20) > [ 198.305382] [] (drm_fb_helper_output_poll_changed) from > [] (drm_kms_helper_hotplug_event+0x34/0x38) > [ 198.305409] [] (drm_kms_helper_hotplug_event) from [] > (output_poll_execute+0x16c/0x17c) > [ 198.305440] [] (output_poll_execute) from [] > (process_one_work+0x1e0/0x368) > [ 198.305466] [] (process_one_work) from [] > (worker_thread+0x2a0/0x418) > [ 198.305511] [] (worker_thread) from [] > (kthread+0x144/0x15c) > [ 198.305539] [] (kthread) from [] > (ret_from_fork+0x14/0x2c) > [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) > [ 198.305562] 9fa0: > > [ 198.305578] 9fc0: > > [ 198.305591] 9fe0: 0013 > [ 198.305630] ---[ end trace 9c4071c657268b83 ]--- > > I also dumped clk_summary in both cases, but they were identical. > > Are their any helpful information, which i can provide? I doubt this will fix your problem, but can you try with this patch [1] applied? Also, is u-boot touching PLLH or anything related to HDMI? [1]https://patchwork.kernel.org/patch/10207159/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
