[Bug 93782] [i9xx TV][BISECT] vblank wait timeout on crtc

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=93782

--- Comment #32 from Felix Schwarz <felix.schwarz at oss.schwarz.eu> ---
Created attachment 128625
  --> https://bugs.freedesktop.org/attachment.cgi?id=128625&action=edit
dmesg Linux 4.9 with disabled cxsr hack

(In reply to Maarten Lankhorst from comment #31)
> Did anyone here test the patch I provided, for those with >100 us delays in
> their pipe updates?

Well I think andram did (comment #15, comment #16).

I did not comment earlier as andram bisected the problem back to 4.6 change
when my problems (and the initial reporter's problem) started much earlier (see
comment 14). However just to be sure I applied your patch on top of git commit
69973b83(4.9) but that does not solve the problem for me (traceback attached).

I started to bisect the problem on my machine but this a quite time consuming
process. First of all the machine itself is quite slow and this hardware is
ancient - but I somehow I despise to retire a machine due to a regression in
the Linux kernel.

However the main problem is that there is no clear "beginning" but there are
multiple interleaved issues. At risk of dilluting the focus here is what I
found so far:
- Linux 4.2 graphics works fine
- 4.3.0: first traceback (warning in drm_atomic_check_only)
- 4.4-rc1: vblank-wait-timed-out-on-crt1
- 4.4-rc2: vblank-wait-timed-out-on-crt0

With newer kernel versions the symptoms become more severe for me: For example
right now (4.8.x) I see multi-second screen freezes during the boot process and
whenever the screen is activated (e.g. resuming).

However not all computers with this chipset are affected so it seems some of
them need some kind of workaround due to connectors, bios, ...

One thing I noticed in my dmesg is:
> [Firmware Bug]: Duplicate ACPI video bus devices for the same VGA controller, please try module parameter "video.allow_duplicates=1"if the current driver doesn't work.

("video.allow_duplicates=1" does not make any difference for me)

My current speculation is that something in the initial atomic conversion broke
this specific chip set and this bug is exposed more often as more and more
parts of the driver rely on atomic helpers/correct atomic behavior.

I'll continue to bisect the bug on my machine but it will take time as I have
more pressing issues on my plate.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20161222/25aef8d9/attachment.html>