Re: [BUG] drm/vc4: vblank wait timed out

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 6 May 2018 01:56:36 +0200 (CEST)
Stefan Wahren <stefan.wahren@xxxxxxxx> wrote:

> > Boris Brezillon <boris.brezillon@xxxxxxxxxxx> hat am 5. Mai 2018 um 20:00 geschrieben:
> > 
> > 
> > On Sat, 5 May 2018 19:44:57 +0200 (CEST)
> > Stefan Wahren <stefan.wahren@xxxxxxxx> wrote:
> >   
> > > Hi Stefan,
> > >   
> > > > Stefan Schake <stschake@xxxxxxxxx> hat am 5. Mai 2018 um 19:29
> > > > geschrieben:
> > > > 
> > > > 
> > > > On Sat, May 5, 2018 at 1:47 PM, Stefan Wahren
> > > > <stefan.wahren@xxxxxxxx> 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.

_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux