Bug 71427 - [IVB] static/desync on hdmi link after switching a bunch of times, no modesets
Summary: [IVB] static/desync on hdmi link after switching a bunch of times, no modesets
Status: CLOSED NOTOURBUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-09 12:51 UTC by necbot
Modified: 2017-07-24 22:56 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description necbot 2013-11-09 12:51:47 UTC
I built a PC using an Intel motherboard, my specs are….

Intel DH77DF Motherboard
Intel G1620 Celeron
2 GB Corsair DDR3-1333
1 TB Western Digital hard drive

My TV is a Samsung LN40C630

This box is running Ubuntu 13.04 on it (but I also tested running OpenELEC 3.2.1 32 bit) on it. This computer is connected to my TV through an HDMI cable (HDMI port 2 of my TV). Also, my Tivo it connected to my TV through an HDMI cable (HDMI port 1 of my TV).

THE PROBLEM
When I turn on my HTPC I sometimes leave it on and switch my TV source to my Tivo so I can watch TV for a while. The problem is that after I’m done watching my Tivo, when I switch back to my HTPC (HDMI port 2) the screen goes black and then shows static. This pattern of static and then black repeats every three seconds or so. It looks like the TV is trying to connect to the HTPC but that it can’t. This does not always happen, it happens maybe 20% of the time. I can almost always fix this by switching the TV back to my Tivo (HDMI port 1) and then back to my HTPC (HDMI port 2) AGAIN. However, this does not always work. Another tactic is to unplug the HDMI cable coming from the HTPC and plug it back in. None of these are real solutions though. I did some troubleshooting and there is what I found…

TROUBLESHOOTING

At first I tried switching HDMI cables.  I tried several cables that I've used problem-free on my other TVs and the error still occured. Then I tried different HDMI ports on the TV.  I doubted this was the issue because none of my TV's HDMI ports have ever given me any issue with any other device.  However, I tried this anyway and no matter which port I used, the error still occured.  The motherboard has a DVI port so I tried using a DVI to HDMI adapter and the error still occurs even through the motherboards DVI port.  I tried other useless thing such as adjust in sleep timeouts, screensaver settings, etc etc. and the error still occurs.  Only using a DVI to VGA adapter resulted in no error occuring.  I also tried switching up my motherboard.  I tried a Asrock H77M-ITX and an Intel DH61AG and both boards have this error.  I also tried using different distros of linux (Openelec, Ubuntu, Wattos).  All the linxu distros had this error.  I tried installing Windows 7 and it worked fine, so I'm certain this is an issue between my TV and linux.


SUMMARY
So to recap…. The HDMI cables are fine. The HDMI ports on my TV and Motherboard are fine. The error does not occur when I’m running Windows. The error occurs when I’m running a Linux distro. Different motherboards showed the same error.  The error is HDMI/DVI related. I'm guessing this in an xserver or Intel driver issue. Help!
Comment 1 Daniel Vetter 2013-11-09 13:15:02 UTC
Please boot with drm.debug=0xe added to your kernel cmdline, reproduce the issue and then attach the complete dmesg. Please make sure the dmesg is complete (i.e. includes all the early boot stuff).

Also please test latest kernels, ubunut has a drm-intel-experimental ppa with all the latest code built from drm-intel-nightly.
Comment 2 necbot 2013-11-10 03:36:49 UTC
Here is a copy of my dmesg with drm.debug=0xe.  Hopefully pastebin is okay.

http://paste.ubuntu.com/6391649/

I switched between my Tivo and HTPC five time and the error occurred twice.

At 65.5 seconds I was able to switch between my Tivo and HTPC with no error.
At 87.8 I was able to switch between my Tivo and HTPC with no error.
Then I made two attempts at switching between my Tivo and HTPC 106.6 and 123.4 that both produced the error.  
At 139.3 I was able to switch between my Tivo and HTPC with no error.


I will test the builds from the drm-intel-experimental ppa and report back.  Would the Xorg bleeding edge ppa be a better choice?  Thanks.
Comment 3 necbot 2013-11-10 04:38:41 UTC
Is this the ppa you were talking about?  How do I add this?  Do I put it in my /etc/apt/sources.list?

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/
Comment 4 necbot 2013-11-10 13:01:19 UTC
Okay, I installed the kernel from here...

http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-nightly/2013-11-09-trusty/

The error still occurs.  

Then I added the xorg bleeding edge ppa and updated my xserver.  The error still occurs though.  Is there anything else I can try?
Comment 5 Daniel Vetter 2013-11-10 13:49:14 UTC
Uploading logs as attachments is highly preferred since pastebins tend to forget them. This is e.g. important if someone needs to dig through old bugzillas when trying to understand the exact reasons for a commit again. Doesn't happen often, but occasionally.

I've tried to attach it myself but bloody ubunut pastebin doesn't allow to grab the raw text without logging in. So please reupload as an attachment.

Now I've looked through your logs and there isn't really anything indicating that something goes wrong. Also, the kernel does no modesets at all, so we just keep on pumping out the pixels.

The only thing which could affect things is the hdmi buffer tuning settings, but they're supposed to be set up by the BIOS - our driver never updates them. So probably not worth chasing.

The other thing to test is whether doing a dpms on/off helps to restore the display? You can just use

$ xset dpms force off ; xset dpms force on
Comment 6 necbot 2013-11-10 14:49:28 UTC
I think we're making progress.  Running dpms on/off command restores the display.  So it's not a driver issue?  It's an issue with dpms?
Comment 7 Daniel Vetter 2013-11-11 06:46:37 UTC
(In reply to comment #6)
> I think we're making progress.  Running dpms on/off command restores the
> display.  So it's not a driver issue?  It's an issue with dpms?

I think it's an issue with the TV, and it gets masked on Windows because that automatically makes a dpms on/off cycle when unplugging/replugging. Linux keeps the pixels flowing by default (but many desktop enviroments do the same as windows by default).

Given that TVs are usually really horribly with their HDMI ports I'd say best to close this as a hw issue, I don't think there's really anything we can do. Sorry for the bad news, but thanks anyway for reporting this.
Comment 8 necbot 2013-11-11 13:03:35 UTC
One thing I did not mention is my original post is that this issue does not occur when using an Nvidia GPU.  

I also have an Acer Aspire Revo R1600, which has an Nvidia ION GPU that I run the OpenELEC ION build on and it never has a problem.  However, when I load OpenELEC (generic build or OS drivers) on my HTPC this issue always occurs.  If my TV were the problem, wouldn't I have seen this bug on my Acer Revo when running the ION build of OpenELEC?  This is part of the reason I think it's an Intel GPU issue related to Linux because my TV works fine when I'm using OpenELEC on an Nvidia GPU.  Is there some way that the Nvidia Linux drivers interact with the screen that would cause this difference?
Comment 9 Daniel Vetter 2013-11-11 19:13:54 UTC
Could be that the nvidia drivers does the same as windows. Or that it only happens on Intel because the signal is a bit more or. Or ... tons of reasons really ;-)
Comment 10 necbot 2013-11-11 19:37:11 UTC
Okay, so it looks like I should play around with the dpms settings.  I could try seeing what settings my Acer Revo uses and mimic them on the Intel HTPC.  

I was thinking that if a dpms cycle fixes the issue then maybe I should create a script that executes a dpms cycle whenever the monitor switches.  I'm not sure how to do this, but I'm assuming it's possible.  I know that this is getting off the subject of a bug fix, but if you any hints on how to do this would be much appreciated :)
Comment 11 necbot 2013-11-11 20:14:02 UTC
One more question.  I found this site...

http://wiki.openelec.tv/index.php?title=Config_EDID_nvidia

The solution they describe here seems to be saving the EDID from my TV.  I already know what this is so I guess I'd have to save it as a bin file and set up an xorg.conf file to point to it.  It seems to so something similar to those DVI Detective switches I see where it remembers the EDID from the TV.  Do you think something like this would work? I haven't worked much with xserver until now so If I'm way off, please let me know.  Thanks.
Comment 12 Daniel Vetter 2013-11-11 21:33:06 UTC
(In reply to comment #11)
> One more question.  I found this site...
> 
> http://wiki.openelec.tv/index.php?title=Config_EDID_nvidia
> 
> The solution they describe here seems to be saving the EDID from my TV.  I
> already know what this is so I guess I'd have to save it as a bin file and
> set up an xorg.conf file to point to it.  It seems to so something similar
> to those DVI Detective switches I see where it remembers the EDID from the
> TV.  Do you think something like this would work? I haven't worked much with
> xserver until now so If I'm way off, please let me know.  Thanks.

afaict from the logs we don't have any issues with reading the EDID. So caching that somewhere won't help. The howto looks more like it's to address userspace that can't transparently handling hot-plugging of the TV after everything is booted.
Comment 13 necbot 2013-11-24 16:12:49 UTC
Not sure this is worth reexamining, but I noticed that the dpms on/off cycling actually does not resolve this issue.  It works most of the time, that's why I said in my earlier comments that this works, but now that I've used it repeatedly I'm finding that sometimes even a dpms on/off will not display the image properly.

I also tried testing this build on my neighbors Westinghouse TV.  The same issue occurs.  The Acer with the NVIDIA ION works fine, but the HTPC with the Intel GPU causes the Westinghouse TV to go black (just black, no static/black).

So if this isn't a bug with the Intel driver, what could be causing it?  Is this just a case of the xserver Intel GPU driver being poorly implemented for TVs?  Is there another compatible graphics driver I could try with this build?  Thanks.
Comment 14 Daniel Vetter 2013-11-25 09:32:49 UTC
The display driver is all in the kernel, so the ddx (or display server in general) doesn't really matter. So I'm a bit at a loss here. I'll reopen just to have a reminder, please post updates if you notice anything interesting.
Comment 15 necbot 2013-12-04 14:04:35 UTC
Hello Daniel,

You can close this if you want.  The place I work at has three TVs, a Sony and two Pioneers, I tested my Acer Revo (NVIDIA GPU) and my HTPC (Intel GPU) on all three and there were no issues.  In addition, my wife and I took advantage of the Black Friday/Cyber Monday sales and bought small Samsung HDTV.  The HTPC (Intel GPU) works perfectly on this TV.  I called up the Samsung and asked why one device would work perfectly on one TV and not the other.  They didn't have an explaination.  They said that someone would get back to me but I'm not going to hold my breath.  The only reason I can see the error happening on the Westinghouse and my other Samsung TV is that both of these TVs are older, they were made about three years ago.  The three TVs at work are fairly new (1-2 years old) and the Samsung that I just bought is the latest model.  Whatever was causing the issue is probably not worth pursuing.  Maybe one day Samsung will make a BIOS update for the Samsung that I'm having the issue with.  For now I'll just use the HTPC on the new Samsung TV that works.  Thanks for all your help!  I really appreciate the time you took to look into this for me :)
Comment 16 Daniel Vetter 2013-12-04 14:12:30 UTC
Thanks for the update, I'll happily blame it all on Samsung ;-)


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.