| Summary: | i915 intel_tv_detect time out with recent kernels: [drm_kms_helper] flip_done timed out | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Zakhar <alainb06> | ||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||
| Severity: | normal | ||||||||
| Priority: | low | CC: | intel-gfx-bugs, kai.heng.feng, tomasz.marcinkowski, villeneuve | ||||||
| Version: | unspecified | ||||||||
| Hardware: | x86-64 (AMD64) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | Triaged, ReadyForDev | ||||||||
| i915 platform: | I965GM | i915 features: | display/Other | ||||||
| Attachments: |
|
||||||||
|
Description
Zakhar
2018-05-06 16:30:56 UTC
More information.
I have narrowed it down:
16.04.1 - kernel 4.4.0-31-generic
==> Works OK with messages ("encoder detached but still enabled on pipe A.")
No visible slowdown apart for 3 or 4 stack traces in the log.
16.04.2 - kernel 4.8.0-36-generic
==> Shows the "time outs" bug
So there must have been a change that is affecting i915 between kernels 4.4. and 4.8
Steps to reproduce:
- live boot on 16.04.1
- see all is Ok apart from some messages in the log
- live boot on 16.04.2
- see the boot takes much much more time and there are numerous timeouts messages.
Are you able to reproduce this with the latest drm-tip? Hi, I would need some help, or at least a pointer (link) to instructions on how to try that. What I tried (the above) can be reproduced 100% of the time with the latest Ubuntu 18.04 and its 4.15 (generic) kernel. The behaviour (several 10 sec time outs) existed since kernel 4.8 I have already done patch of my own on packages like tor, and even done my own packages, but never played with the kernel... There are some instructions here: https://01.org/linuxgraphics/documentation/build-guide-0 Thanks! Looks quite simple. Do you suggest I build only the kernel for now, or do I need to build all the shebang? Just kernel (drm-tip) And please send dmesg with drm.debug=0x1e log_buf_len=4M? Ok, will do! I assume that goes in the "kernel command line" (startup) as instructed by: https://01.org/linuxgraphics/documentation/how-report-bugs I am currently doing a full backup of the system in case I mess up things, and will then do installation of 18.04 (on external device) + compile drm-tip kernel and report. ... it takes some time on that machine that was already low specced 10 years ago! Created attachment 139405 [details]
dmesg with drm-tip 4.17.0-rc3+ kernel
As requested, I attached the FULL dmesg with drm-tip kernel. There are a few 'fails' in the startup, but they look unrelated to the video driver (snap, audio driver...) The "bug" (flip_done timed out) is still there, making the boot process painfully long! Please don't hesitate to tell if you need anymore information for this 'regression'. I've been having flip_done timeouts for a long time. Two suggestions I've been offered: 1. add "video=SVIDEO-1:d" to your kernel boot options 2. remove the intel_drv.so module Given the presence of intel_tv_detect in the trace, bug #93782 might be relevant. Also if you've been seeing this since 4.8, you might try reverting ea0000f0 "Roll out the helper nonblock tracking". This can be done up to kernel 4.14, after that it's too complicated. @Jim Rees Thanks, your suggestion #1 made the bug disappear... as far as I could see in the log (the PC is remote ~1000km away, so I can't see what is happening on the screen!) I tested it both with the self compiled drm-debug kernel and with stock Ubuntu 4.15 kernel. (I didn't test yet on current 3.13 since in 3.13 there are messages in the log but no timeouts, so it is not really an issue) The suggestion #2 seems very strange. Isn't it like running without the specific intel driver? Sure when I add "nomodeset" (or use the "recovery" grub options) that works fine with no time outs since we use no special video driver. But then we loose graphic acceleration which I still want to keep. No graphic acceleration is noticeable even in Firefox, and would not be a nice option. I don't completely accept the workaround just now, since I am not in front of the PC and can't see by myself what are the side effects of this boot parameter. I will also have to find a clean way to make this boot parameter stick, even when a new kernel is proposed on the Ubuntu repos... but I guess this is a common issue unrelated to Intel drivers. So the option #1 you propose Jim looks promising... sure it is not a fix but a workaround! I could anyway understand, considering the age of the hardware and how long it has been "end of life" now, that fixing this issue is not Intel engineers priority once I confirm the workaround. (In reply to Jim Rees from comment #11) > 1. add "video=SVIDEO-1:d" to your kernel boot options What this does is force disable the TV-out, leading to skipping the load detection that times out on vblank wait. I'm not optimistic on figuring out what caused this without a bisect result. Thanks for the precision on the effect of this parameter. We have used this PC connected to a TV, but that was with a VGA cable, through the VGA-out socket, the TV having a VGA-In connetor. I am not sure whether that counts as "TV-Out" and is one of the tests I need to do for this workaround. This PC being "remote", I'll be able to complete that test only 1st week of June, where I'll have access to the hardware. As for bisecting... do you have a pointer on documentation I could use to see the complexity of that? Sure the time-out appear somewhere between kernels 4.4 and 4.8, and that could be lower/upper bisection limits. Not sure though it is really practical starting bisecting with a remote machine!.. (In reply to Zakhar from comment #14) > We have used this PC connected to a TV, but that was with a VGA cable, > through the VGA-out socket, the TV having a VGA-In connetor. I am not sure > whether that counts as "TV-Out" and is one of the tests I need to do for > this workaround. This is not about VGA (regardless of whether it's connected to a TV), this is about SVIDEO. It's also possible your board doesn't even have a TV-out, which causes the timeout. Come to think of it, please attach /sys/kernel/debug/dri/0/i915_vbt. > As for bisecting... do you have a pointer on documentation I could use to > see the complexity of that? Sure the time-out appear somewhere between > kernels 4.4 and 4.8, and that could be lower/upper bisection limits. Not > sure though it is really practical starting bisecting with a remote > machine!.. https://wiki.ubuntu.com/Kernel/KernelBisection *** This bug has been marked as a duplicate of bug 93782 *** (In reply to Ville Syrjala from comment #16) > > *** This bug has been marked as a duplicate of bug 93782 *** Thanks Ville. This sounded vaguely familiar, dunno why I didn't find the bug. Zakhar, please do attach the vbt here regardless. Hi, I will provide the file, along with a more complete confirmation (or not!) that the boot option is a complete workaround, between June 2nd and June 10th: when I will have direct access to the hardware! Created attachment 139963 [details]
i915.vbt as requested
I hope this helps since I had to copy (cp) from the root protected directory to /tmp, in order to avoid to having to sudo firefox for posting that!
I provided the i915.vbt as requested. I hope doing a sudo cp to /tmp worked ok. The hardware (Dell Inspiron 1525) has: - built in screen (1280x800) - VGA-Out - HDMI With the workaround, I could test built-in screen and VGA-Out work fine. As for HDMI, I don't have a cable (no big deal!) Graphic acceleration is present. There are no more messages in the log about slow graphics or timeouts, that is even true for 14.04 (3.13 kernel) where we had messages but no timeout. As for that hardware the workaround is perfect. I have read the bissect procedure, considering how slow this old hardware is (it takes quite a long time to compile a kernel!) and the fact that the workaround is about a parameter to add in /etc/default/grub and works fine on this PC with no adverse effect, I won't start bissecting. I am then Ok with the "low" urgency on this bug. I'll remove the workaround if you ever find why there is now some timeouts in recent kernels on this "TV detection". |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.