FS#51703 - [linux] kernel error in drm_kms_helper, flip_done timed out

Attached to Project: Arch Linux
Opened by Nils Naumann (naund) - Saturday, 05 November 2016, 09:46 GMT
Last edited by Andreas Radke (AndyRTR) - Sunday, 27 February 2022, 10:42 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 13
Private No



Since update to 4.8.2 I've got the following log entry, after 10s delay during booting:

[ 12.000117] [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* [CRTC:26:pipe A] flip_done timed out

See also the following forum thread: https://bbs.archlinux.org/viewtopic.php?id=218581

Afer some googling I found someone mentioning a bug in drm-misc, which should be resolved now:

Daniel Vetter - Sept. 2, 2016, 6:11 a.m.

On Fri, Sep 2, 2016 at 1:48 AM, David Herrmann <dh.herrmann@gmail.com> wrote:
> So either the drm_simple_kms_helpers are buggy, or the SimpleDRM use
> of it. On DPMS updates, I get:
> Sep 02 01:00:39 david-t2 kernel:
> [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR*
> [CRTC:25:crtc-0] flip_done timed out
> Sep 02 01:00:39 david-t2 kernel: ------------[ cut here ]------------
> Sep 02 01:00:39 david-t2 kernel: WARNING: CPU: 3 PID: 352 at
> drivers/gpu/drm/drm_atomic_helper.c:1549
> drm_atomic_helper_commit_hw_done+0xab/0xb0 [drm_kms_helper]
> The atomic-commit originates in:
> drm_atomic_helper_connector_dpms()
> Any idea what is missing there? I haven't looked much into the
> atomic-helpers, yet.

The bugfix for that is in latest drm-misc (or well, should be at
least). And you need to make sure to call drm_crtc_send_vblank_event
(if there's an event) from your update hook. That /should/ work, but I
didn't test it myself. flip_done not happening is when the
driver/helpers fail to submit the event for some reason or another.

Additional info:
* package version(s): linux 4.8.2 up to 4.8.6
* config and/or log files etc.



Steps to reproduce:
This task depends upon

Closed by  Andreas Radke (AndyRTR)
Sunday, 27 February 2022, 10:42 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed upstream
Comment by Grzegorz M. (grzechoo) - Friday, 11 November 2016, 16:17 GMT
Same issue here with kernel 4.8.7-1-ARCH.
Attached kernel log and hwinfo.

Comment by Joachim Deiniol (JoachimDeiniol) - Monday, 14 November 2016, 12:21 GMT
same issue 4.8.7-1-ARCH
Comment by Chris (ArchChris) - Wednesday, 23 November 2016, 09:19 GMT
same issue in 4.8.8-2. it seems, the problem is related to GM965
same issue in 4.8.10-1. but it got WORSE.

in 4.8.8-2 i get it at the CLI login. in 4.8.10-1 the display goes black upon boot and i have to use the advanced option to even get to the CLI login, where the error shows again.
Comment by Michele Stuart (crystalbrier) - Thursday, 15 December 2016, 03:29 GMT
Same issue on 4.8.13. Can require multiple power cycles to complete the boot process on a late 2008 MacBook.
Comment by Rishabh Nagendra (devilsworkshop) - Tuesday, 10 January 2017, 05:34 GMT
On 4.8.13-1, bootup goes fine (straight to the SLIM display manager). But the moment I try and switch to a different TTY, the whole display freezes, and I get the same error message as OP. (sometimes I have to switch TTYs a few times to trigger it)

While I can't interact with the display, I can SSH in just fine and everything works, with the exception of the reboot/poweroff commands. They take about ~5 minutes to execute, although they do shut down the SSH daemon. Same with the magic SysRq combination.
Comment by Michael (micele) - Tuesday, 10 January 2017, 12:40 GMT
I can confirm the same for every kernel since 4.7.6. I try every new kernel release ever since, but the bug remains. CLI login works from time to time with significant delay, LightDM starting up freezes the machine.

   hwinfo.txt (472.5 KiB)
Comment by wombalton (wombalton) - Saturday, 08 April 2017, 08:59 GMT
As suggested by the forum thread [1] I added video=SVIDEO-1:d to my kernel boot parameters. This disables the SVIDEO connector. I don't need it, so I could solved the Bug for me! (currently on 4.10.8-1)
[1] https://bbs.archlinux.org/viewtopic.php?pid=1689914#p1689914
Comment by Diego Viola (diegoviola) - Wednesday, 31 May 2017, 12:18 GMT
Same issue here, 4.11.3-1-ARCH.

00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)
   hwinfo (280.8 KiB)
Comment by Chris (ArchChris) - Wednesday, 31 May 2017, 20:41 GMT
Actually, for me the problem has been gone for a while. As far as I remember, it was some setting in the grub settings for "svideo". See here:
Comment by Diego Viola (diegoviola) - Tuesday, 27 June 2017, 17:54 GMT
I had a "flip_done timed out" issue that got fixed recently:


Please check if that fixes the issue that you have, i.e. try the latest drm-tip.

If it does not, please file a bug report against DRM/Intel here:

Comment by c (c) - Friday, 10 November 2017, 04:17 GMT
Happens here when exiting Xorg since 4.9.61 and 4.13.12.
Comment by Luis Bourgard (unnilquadium) - Friday, 26 January 2018, 19:08 GMT
Still present in 4.14.14
It only happens with the xf86-video-intel package installed (running on a laptop with intel integrated graphics on an i5-2410m).
Uninstalling that package fixes the issue, but it also introduces some screen tearing.
Comment by Joachim Deiniol (JoachimDeiniol) - Saturday, 27 January 2018, 10:22 GMT
IMO Luis Bourgard was explaining a workaround and not complaining.. ;-)

aladhater: Please consider using the unsubscribe button, if comments like these bother you too much. THANK YOU!
Comment by Eli Schwartz (eschwartz) - Sunday, 28 January 2018, 03:01 GMT
1) obvious trollwords
2) disposable email address
3) trollish username
4) registered yesterday for this comment alone
5) comment duly deleted, we will see what happens

Sorry :D
Comment by Luis Bourgard (unnilquadium) - Sunday, 28 January 2018, 10:32 GMT
I've created a new forum thread ( https://bbs.archlinux.org/viewtopic.php?id=233957 ) for further discussion.

Thanks :)
Comment by Luis Bourgard (unnilquadium) - Friday, 01 May 2020, 07:55 GMT
For information, I can no longer reproduce this bug.
xf86-video-intel version 1:2.99.917+906+g846b53da-1
Linux Kernel version 5.6.7.arch1-1
Comment by Jim Rees (JimRees) - Monday, 12 October 2020, 20:59 GMT
I believe this has been fixed upstream as of kernel 5.0, but I'm not absolutely certain it's the same bug. Is anyone still seeing this?

Here is the upstream report:
Comment by Luis Bourgard (unnilquadium) - Monday, 12 October 2020, 21:35 GMT
This error was easily reproducible on my machine, but it's been absent for many months. I don't know since when...
I'm happy to accept it as fixed.