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] [<c010f8d8>] (unwind_backtrace) from [<c010cda4>] (show_stack+0x20/0x24) [ 198.304934] [<c010cda4>] (show_stack) from [<c079ae74>] (dump_stack+0x20/0x28) [ 198.304971] [<c079ae74>] (dump_stack) from [<c011e61c>] (__warn+0xec/0x104) [ 198.305012] [<c011e61c>] (__warn) from [<c011e67c>] (warn_slowpath_fmt+0x48/0x50) [ 198.305048] [<c011e67c>] (warn_slowpath_fmt) from [<c0421638>] (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] [<c0421638>] (drm_atomic_helper_wait_for_vblanks) from [<c0455ce8>] (vc4_atomic_complete_commit+0x80/0xb8) [ 198.305144] [<c0455ce8>] (vc4_atomic_complete_commit) from [<c0455e30>] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] [<c0455e30>] (vc4_atomic_commit) from [<c043dbac>] (drm_atomic_commit+0x50/0x60) [ 198.305202] [<c043dbac>] (drm_atomic_commit) from [<c04251e4>] (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] [<c04251e4>] (restore_fbdev_mode_atomic) from [<c0426a8c>] (restore_fbdev_mode+0x38/0x144) [ 198.305270] [<c0426a8c>] (restore_fbdev_mode) from [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) [ 198.305296] [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0428030>] (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [<c0428030>] (drm_fb_helper_set_par) from [<c0427f44>] (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] [<c0427f44>] (drm_fb_helper_hotplug_event) from [<c0428078>] (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] [<c0428078>] (drm_fb_helper_output_poll_changed) from [<c0419494>] (drm_kms_helper_hotplug_event+0x34/0x38) [ 198.305409] [<c0419494>] (drm_kms_helper_hotplug_event) from [<c041963c>] (output_poll_execute+0x16c/0x17c) [ 198.305440] [<c041963c>] (output_poll_execute) from [<c01337e4>] (process_one_work+0x1e0/0x368) [ 198.305466] [<c01337e4>] (process_one_work) from [<c0134620>] (worker_thread+0x2a0/0x418) [ 198.305511] [<c0134620>] (worker_thread) from [<c0138fa8>] (kthread+0x144/0x15c) [ 198.305539] [<c0138fa8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] 9fa0: 00000000 00000000 00000000 00000000 [ 198.305578] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 198.305591] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 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
On Sat, 5 May 2018 13:47:25 +0200 (CEST) Stefan Wahren stefan.wahren@i2se.com 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] [<c010f8d8>] (unwind_backtrace) from [<c010cda4>] (show_stack+0x20/0x24) [ 198.304934] [<c010cda4>] (show_stack) from [<c079ae74>] (dump_stack+0x20/0x28) [ 198.304971] [<c079ae74>] (dump_stack) from [<c011e61c>] (__warn+0xec/0x104) [ 198.305012] [<c011e61c>] (__warn) from [<c011e67c>] (warn_slowpath_fmt+0x48/0x50) [ 198.305048] [<c011e67c>] (warn_slowpath_fmt) from [<c0421638>] (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] [<c0421638>] (drm_atomic_helper_wait_for_vblanks) from [<c0455ce8>] (vc4_atomic_complete_commit+0x80/0xb8) [ 198.305144] [<c0455ce8>] (vc4_atomic_complete_commit) from [<c0455e30>] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] [<c0455e30>] (vc4_atomic_commit) from [<c043dbac>] (drm_atomic_commit+0x50/0x60) [ 198.305202] [<c043dbac>] (drm_atomic_commit) from [<c04251e4>] (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] [<c04251e4>] (restore_fbdev_mode_atomic) from [<c0426a8c>] (restore_fbdev_mode+0x38/0x144) [ 198.305270] [<c0426a8c>] (restore_fbdev_mode) from [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) [ 198.305296] [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0428030>] (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [<c0428030>] (drm_fb_helper_set_par) from [<c0427f44>] (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] [<c0427f44>] (drm_fb_helper_hotplug_event) from [<c0428078>] (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] [<c0428078>] (drm_fb_helper_output_poll_changed) from [<c0419494>] (drm_kms_helper_hotplug_event+0x34/0x38) [ 198.305409] [<c0419494>] (drm_kms_helper_hotplug_event) from [<c041963c>] (output_poll_execute+0x16c/0x17c) [ 198.305440] [<c041963c>] (output_poll_execute) from [<c01337e4>] (process_one_work+0x1e0/0x368) [ 198.305466] [<c01337e4>] (process_one_work) from [<c0134620>] (worker_thread+0x2a0/0x418) [ 198.305511] [<c0134620>] (worker_thread) from [<c0138fa8>] (kthread+0x144/0x15c) [ 198.305539] [<c0138fa8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] 9fa0: 00000000 00000000 00000000 00000000 [ 198.305578] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 198.305591] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 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?
Hi Boris,
Boris Brezillon boris.brezillon@bootlin.com hat am 5. Mai 2018 um 14:24 geschrieben:
On Sat, 5 May 2018 13:47:25 +0200 (CEST) Stefan Wahren stefan.wahren@i2se.com 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] [<c010f8d8>] (unwind_backtrace) from [<c010cda4>] (show_stack+0x20/0x24) [ 198.304934] [<c010cda4>] (show_stack) from [<c079ae74>] (dump_stack+0x20/0x28) [ 198.304971] [<c079ae74>] (dump_stack) from [<c011e61c>] (__warn+0xec/0x104) [ 198.305012] [<c011e61c>] (__warn) from [<c011e67c>] (warn_slowpath_fmt+0x48/0x50) [ 198.305048] [<c011e67c>] (warn_slowpath_fmt) from [<c0421638>] (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] [<c0421638>] (drm_atomic_helper_wait_for_vblanks) from [<c0455ce8>] (vc4_atomic_complete_commit+0x80/0xb8) [ 198.305144] [<c0455ce8>] (vc4_atomic_complete_commit) from [<c0455e30>] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] [<c0455e30>] (vc4_atomic_commit) from [<c043dbac>] (drm_atomic_commit+0x50/0x60) [ 198.305202] [<c043dbac>] (drm_atomic_commit) from [<c04251e4>] (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] [<c04251e4>] (restore_fbdev_mode_atomic) from [<c0426a8c>] (restore_fbdev_mode+0x38/0x144) [ 198.305270] [<c0426a8c>] (restore_fbdev_mode) from [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) [ 198.305296] [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0428030>] (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [<c0428030>] (drm_fb_helper_set_par) from [<c0427f44>] (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] [<c0427f44>] (drm_fb_helper_hotplug_event) from [<c0428078>] (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] [<c0428078>] (drm_fb_helper_output_poll_changed) from [<c0419494>] (drm_kms_helper_hotplug_event+0x34/0x38) [ 198.305409] [<c0419494>] (drm_kms_helper_hotplug_event) from [<c041963c>] (output_poll_execute+0x16c/0x17c) [ 198.305440] [<c041963c>] (output_poll_execute) from [<c01337e4>] (process_one_work+0x1e0/0x368) [ 198.305466] [<c01337e4>] (process_one_work) from [<c0134620>] (worker_thread+0x2a0/0x418) [ 198.305511] [<c0134620>] (worker_thread) from [<c0138fa8>] (kthread+0x144/0x15c) [ 198.305539] [<c0138fa8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] 9fa0: 00000000 00000000 00000000 00000000 [ 198.305578] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 198.305591] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 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
On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren stefan.wahren@i2se.com 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] [<c010f8d8>] (unwind_backtrace) from [<c010cda4>] (show_stack+0x20/0x24) [ 198.304934] [<c010cda4>] (show_stack) from [<c079ae74>] (dump_stack+0x20/0x28) [ 198.304971] [<c079ae74>] (dump_stack) from [<c011e61c>] (__warn+0xec/0x104) [ 198.305012] [<c011e61c>] (__warn) from [<c011e67c>] (warn_slowpath_fmt+0x48/0x50) [ 198.305048] [<c011e67c>] (warn_slowpath_fmt) from [<c0421638>] (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] [<c0421638>] (drm_atomic_helper_wait_for_vblanks) from [<c0455ce8>] (vc4_atomic_complete_commit+0x80/0xb8) [ 198.305144] [<c0455ce8>] (vc4_atomic_complete_commit) from [<c0455e30>] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] [<c0455e30>] (vc4_atomic_commit) from [<c043dbac>] (drm_atomic_commit+0x50/0x60) [ 198.305202] [<c043dbac>] (drm_atomic_commit) from [<c04251e4>] (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] [<c04251e4>] (restore_fbdev_mode_atomic) from [<c0426a8c>] (restore_fbdev_mode+0x38/0x144) [ 198.305270] [<c0426a8c>] (restore_fbdev_mode) from [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) [ 198.305296] [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0428030>] (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [<c0428030>] (drm_fb_helper_set_par) from [<c0427f44>] (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] [<c0427f44>] (drm_fb_helper_hotplug_event) from [<c0428078>] (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] [<c0428078>] (drm_fb_helper_output_poll_changed) from [<c0419494>] (drm_kms_helper_hotplug_event+0x34/0x38) [ 198.305409] [<c0419494>] (drm_kms_helper_hotplug_event) from [<c041963c>] (output_poll_execute+0x16c/0x17c) [ 198.305440] [<c041963c>] (output_poll_execute) from [<c01337e4>] (process_one_work+0x1e0/0x368) [ 198.305466] [<c01337e4>] (process_one_work) from [<c0134620>] (worker_thread+0x2a0/0x418) [ 198.305511] [<c0134620>] (worker_thread) from [<c0138fa8>] (kthread+0x144/0x15c) [ 198.305539] [<c0138fa8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] 9fa0: 00000000 00000000 00000000 00000000 [ 198.305578] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 198.305591] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 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
Hi Stefan,
Stefan Schake stschake@gmail.com hat am 5. Mai 2018 um 19:29 geschrieben:
On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren stefan.wahren@i2se.com 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] [<c010f8d8>] (unwind_backtrace) from [<c010cda4>] (show_stack+0x20/0x24) [ 198.304934] [<c010cda4>] (show_stack) from [<c079ae74>] (dump_stack+0x20/0x28) [ 198.304971] [<c079ae74>] (dump_stack) from [<c011e61c>] (__warn+0xec/0x104) [ 198.305012] [<c011e61c>] (__warn) from [<c011e67c>] (warn_slowpath_fmt+0x48/0x50) [ 198.305048] [<c011e67c>] (warn_slowpath_fmt) from [<c0421638>] (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] [<c0421638>] (drm_atomic_helper_wait_for_vblanks) from [<c0455ce8>] (vc4_atomic_complete_commit+0x80/0xb8) [ 198.305144] [<c0455ce8>] (vc4_atomic_complete_commit) from [<c0455e30>] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] [<c0455e30>] (vc4_atomic_commit) from [<c043dbac>] (drm_atomic_commit+0x50/0x60) [ 198.305202] [<c043dbac>] (drm_atomic_commit) from [<c04251e4>] (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] [<c04251e4>] (restore_fbdev_mode_atomic) from [<c0426a8c>] (restore_fbdev_mode+0x38/0x144) [ 198.305270] [<c0426a8c>] (restore_fbdev_mode) from [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) [ 198.305296] [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0428030>] (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [<c0428030>] (drm_fb_helper_set_par) from [<c0427f44>] (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] [<c0427f44>] (drm_fb_helper_hotplug_event) from [<c0428078>] (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] [<c0428078>] (drm_fb_helper_output_poll_changed) from [<c0419494>] (drm_kms_helper_hotplug_event+0x34/0x38) [ 198.305409] [<c0419494>] (drm_kms_helper_hotplug_event) from [<c041963c>] (output_poll_execute+0x16c/0x17c) [ 198.305440] [<c041963c>] (output_poll_execute) from [<c01337e4>] (process_one_work+0x1e0/0x368) [ 198.305466] [<c01337e4>] (process_one_work) from [<c0134620>] (worker_thread+0x2a0/0x418) [ 198.305511] [<c0134620>] (worker_thread) from [<c0138fa8>] (kthread+0x144/0x15c) [ 198.305539] [<c0138fa8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] 9fa0: 00000000 00000000 00000000 00000000 [ 198.305578] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 198.305591] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 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
On Sat, 5 May 2018 19:44:57 +0200 (CEST) Stefan Wahren stefan.wahren@i2se.com wrote:
Hi Stefan,
Stefan Schake stschake@gmail.com hat am 5. Mai 2018 um 19:29 geschrieben:
On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren stefan.wahren@i2se.com 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] [<c010f8d8>] (unwind_backtrace) from [<c010cda4>] (show_stack+0x20/0x24) [ 198.304934] [<c010cda4>] (show_stack) from [<c079ae74>] (dump_stack+0x20/0x28) [ 198.304971] [<c079ae74>] (dump_stack) from [<c011e61c>] (__warn+0xec/0x104) [ 198.305012] [<c011e61c>] (__warn) from [<c011e67c>] (warn_slowpath_fmt+0x48/0x50) [ 198.305048] [<c011e67c>] (warn_slowpath_fmt) from [<c0421638>] (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] [<c0421638>] (drm_atomic_helper_wait_for_vblanks) from [<c0455ce8>] (vc4_atomic_complete_commit+0x80/0xb8) [ 198.305144] [<c0455ce8>] (vc4_atomic_complete_commit) from [<c0455e30>] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] [<c0455e30>] (vc4_atomic_commit) from [<c043dbac>] (drm_atomic_commit+0x50/0x60) [ 198.305202] [<c043dbac>] (drm_atomic_commit) from [<c04251e4>] (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] [<c04251e4>] (restore_fbdev_mode_atomic) from [<c0426a8c>] (restore_fbdev_mode+0x38/0x144) [ 198.305270] [<c0426a8c>] (restore_fbdev_mode) from [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) [ 198.305296] [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0428030>] (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [<c0428030>] (drm_fb_helper_set_par) from [<c0427f44>] (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] [<c0427f44>] (drm_fb_helper_hotplug_event) from [<c0428078>] (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] [<c0428078>] (drm_fb_helper_output_poll_changed) from [<c0419494>] (drm_kms_helper_hotplug_event+0x34/0x38) [ 198.305409] [<c0419494>] (drm_kms_helper_hotplug_event) from [<c041963c>] (output_poll_execute+0x16c/0x17c) [ 198.305440] [<c041963c>] (output_poll_execute) from [<c01337e4>] (process_one_work+0x1e0/0x368) [ 198.305466] [<c01337e4>] (process_one_work) from [<c0134620>] (worker_thread+0x2a0/0x418) [ 198.305511] [<c0134620>] (worker_thread) from [<c0138fa8>] (kthread+0x144/0x15c) [ 198.305539] [<c0138fa8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] 9fa0: 00000000 00000000 00000000 00000000 [ 198.305578] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 198.305591] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 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?
Boris Brezillon boris.brezillon@bootlin.com hat am 5. Mai 2018 um 20:00 geschrieben:
On Sat, 5 May 2018 19:44:57 +0200 (CEST) Stefan Wahren stefan.wahren@i2se.com wrote:
Hi Stefan,
Stefan Schake stschake@gmail.com hat am 5. Mai 2018 um 19:29 geschrieben:
On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren stefan.wahren@i2se.com 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] [<c010f8d8>] (unwind_backtrace) from [<c010cda4>] (show_stack+0x20/0x24) [ 198.304934] [<c010cda4>] (show_stack) from [<c079ae74>] (dump_stack+0x20/0x28) [ 198.304971] [<c079ae74>] (dump_stack) from [<c011e61c>] (__warn+0xec/0x104) [ 198.305012] [<c011e61c>] (__warn) from [<c011e67c>] (warn_slowpath_fmt+0x48/0x50) [ 198.305048] [<c011e67c>] (warn_slowpath_fmt) from [<c0421638>] (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] [<c0421638>] (drm_atomic_helper_wait_for_vblanks) from [<c0455ce8>] (vc4_atomic_complete_commit+0x80/0xb8) [ 198.305144] [<c0455ce8>] (vc4_atomic_complete_commit) from [<c0455e30>] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] [<c0455e30>] (vc4_atomic_commit) from [<c043dbac>] (drm_atomic_commit+0x50/0x60) [ 198.305202] [<c043dbac>] (drm_atomic_commit) from [<c04251e4>] (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] [<c04251e4>] (restore_fbdev_mode_atomic) from [<c0426a8c>] (restore_fbdev_mode+0x38/0x144) [ 198.305270] [<c0426a8c>] (restore_fbdev_mode) from [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) [ 198.305296] [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0428030>] (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [<c0428030>] (drm_fb_helper_set_par) from [<c0427f44>] (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] [<c0427f44>] (drm_fb_helper_hotplug_event) from [<c0428078>] (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] [<c0428078>] (drm_fb_helper_output_poll_changed) from [<c0419494>] (drm_kms_helper_hotplug_event+0x34/0x38) [ 198.305409] [<c0419494>] (drm_kms_helper_hotplug_event) from [<c041963c>] (output_poll_execute+0x16c/0x17c) [ 198.305440] [<c041963c>] (output_poll_execute) from [<c01337e4>] (process_one_work+0x1e0/0x368) [ 198.305466] [<c01337e4>] (process_one_work) from [<c0134620>] (worker_thread+0x2a0/0x418) [ 198.305511] [<c0134620>] (worker_thread) from [<c0138fa8>] (kthread+0x144/0x15c) [ 198.305539] [<c0138fa8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] 9fa0: 00000000 00000000 00000000 00000000 [ 198.305578] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 198.305591] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 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
On Sun, 6 May 2018 01:56:36 +0200 (CEST) Stefan Wahren stefan.wahren@i2se.com wrote:
Boris Brezillon boris.brezillon@bootlin.com hat am 5. Mai 2018 um 20:00 geschrieben:
On Sat, 5 May 2018 19:44:57 +0200 (CEST) Stefan Wahren stefan.wahren@i2se.com wrote:
Hi Stefan,
Stefan Schake stschake@gmail.com hat am 5. Mai 2018 um 19:29 geschrieben:
On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren stefan.wahren@i2se.com 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] [<c010f8d8>] (unwind_backtrace) from [<c010cda4>] (show_stack+0x20/0x24) [ 198.304934] [<c010cda4>] (show_stack) from [<c079ae74>] (dump_stack+0x20/0x28) [ 198.304971] [<c079ae74>] (dump_stack) from [<c011e61c>] (__warn+0xec/0x104) [ 198.305012] [<c011e61c>] (__warn) from [<c011e67c>] (warn_slowpath_fmt+0x48/0x50) [ 198.305048] [<c011e67c>] (warn_slowpath_fmt) from [<c0421638>] (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] [<c0421638>] (drm_atomic_helper_wait_for_vblanks) from [<c0455ce8>] (vc4_atomic_complete_commit+0x80/0xb8) [ 198.305144] [<c0455ce8>] (vc4_atomic_complete_commit) from [<c0455e30>] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] [<c0455e30>] (vc4_atomic_commit) from [<c043dbac>] (drm_atomic_commit+0x50/0x60) [ 198.305202] [<c043dbac>] (drm_atomic_commit) from [<c04251e4>] (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] [<c04251e4>] (restore_fbdev_mode_atomic) from [<c0426a8c>] (restore_fbdev_mode+0x38/0x144) [ 198.305270] [<c0426a8c>] (restore_fbdev_mode) from [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) [ 198.305296] [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0428030>] (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [<c0428030>] (drm_fb_helper_set_par) from [<c0427f44>] (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] [<c0427f44>] (drm_fb_helper_hotplug_event) from [<c0428078>] (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] [<c0428078>] (drm_fb_helper_output_poll_changed) from [<c0419494>] (drm_kms_helper_hotplug_event+0x34/0x38) [ 198.305409] [<c0419494>] (drm_kms_helper_hotplug_event) from [<c041963c>] (output_poll_execute+0x16c/0x17c) [ 198.305440] [<c041963c>] (output_poll_execute) from [<c01337e4>] (process_one_work+0x1e0/0x368) [ 198.305466] [<c01337e4>] (process_one_work) from [<c0134620>] (worker_thread+0x2a0/0x418) [ 198.305511] [<c0134620>] (worker_thread) from [<c0138fa8>] (kthread+0x144/0x15c) [ 198.305539] [<c0138fa8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] 9fa0: 00000000 00000000 00000000 00000000 [ 198.305578] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 198.305591] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 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.
Hi Boris,
Boris Brezillon boris.brezillon@bootlin.com hat am 7. Mai 2018 um 09:11 geschrieben:
On Sun, 6 May 2018 01:56:36 +0200 (CEST) Stefan Wahren stefan.wahren@i2se.com wrote:
Boris Brezillon boris.brezillon@bootlin.com hat am 5. Mai 2018 um 20:00 geschrieben:
On Sat, 5 May 2018 19:44:57 +0200 (CEST) Stefan Wahren stefan.wahren@i2se.com wrote:
Hi Stefan,
Stefan Schake stschake@gmail.com hat am 5. Mai 2018 um 19:29 geschrieben:
On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren stefan.wahren@i2se.com 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] [<c010f8d8>] (unwind_backtrace) from [<c010cda4>] (show_stack+0x20/0x24) [ 198.304934] [<c010cda4>] (show_stack) from [<c079ae74>] (dump_stack+0x20/0x28) [ 198.304971] [<c079ae74>] (dump_stack) from [<c011e61c>] (__warn+0xec/0x104) [ 198.305012] [<c011e61c>] (__warn) from [<c011e67c>] (warn_slowpath_fmt+0x48/0x50) [ 198.305048] [<c011e67c>] (warn_slowpath_fmt) from [<c0421638>] (drm_atomic_helper_wait_for_vblanks+0x1d4/0x1f0) [ 198.305098] [<c0421638>] (drm_atomic_helper_wait_for_vblanks) from [<c0455ce8>] (vc4_atomic_complete_commit+0x80/0xb8) [ 198.305144] [<c0455ce8>] (vc4_atomic_complete_commit) from [<c0455e30>] (vc4_atomic_commit+0x110/0x11c) [ 198.305174] [<c0455e30>] (vc4_atomic_commit) from [<c043dbac>] (drm_atomic_commit+0x50/0x60) [ 198.305202] [<c043dbac>] (drm_atomic_commit) from [<c04251e4>] (restore_fbdev_mode_atomic+0x80/0x1cc) [ 198.305228] [<c04251e4>] (restore_fbdev_mode_atomic) from [<c0426a8c>] (restore_fbdev_mode+0x38/0x144) [ 198.305270] [<c0426a8c>] (restore_fbdev_mode) from [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x58/0x8c) [ 198.305296] [<c0427fa8>] (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c0428030>] (drm_fb_helper_set_par+0x54/0x60) [ 198.305320] [<c0428030>] (drm_fb_helper_set_par) from [<c0427f44>] (drm_fb_helper_hotplug_event+0xc8/0xd4) [ 198.305343] [<c0427f44>] (drm_fb_helper_hotplug_event) from [<c0428078>] (drm_fb_helper_output_poll_changed+0x1c/0x20) [ 198.305382] [<c0428078>] (drm_fb_helper_output_poll_changed) from [<c0419494>] (drm_kms_helper_hotplug_event+0x34/0x38) [ 198.305409] [<c0419494>] (drm_kms_helper_hotplug_event) from [<c041963c>] (output_poll_execute+0x16c/0x17c) [ 198.305440] [<c041963c>] (output_poll_execute) from [<c01337e4>] (process_one_work+0x1e0/0x368) [ 198.305466] [<c01337e4>] (process_one_work) from [<c0134620>] (worker_thread+0x2a0/0x418) [ 198.305511] [<c0134620>] (worker_thread) from [<c0138fa8>] (kthread+0x144/0x15c) [ 198.305539] [<c0138fa8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) [ 198.305549] Exception stack(0xc9939fb0 to 0xc9939ff8) [ 198.305562] 9fa0: 00000000 00000000 00000000 00000000 [ 198.305578] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 198.305591] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 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.
sorry, i didn't tried long enough. Today i was able to reproduce the timeout even without U-Boot. So there is no difference.
Here is the dump with Kernel 4.17rc4 (bcm2835) and U-Boot:
https://gist.github.com/lategoodbye/84f322357f311a5cd232f38b57c11cd4
Regards Stefan
dri-devel@lists.freedesktop.org
-
Boris Brezillon -
Stefan Schake -
Stefan Wahren