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