Bug 46761 - [BISECTED[[ILK] No signal on monitor connected via HDMI
Summary: [BISECTED[[ILK] No signal on monitor connected via HDMI
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Paulo Zanoni
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-31 10:20 UTC by Sudaraka Wijesinghe
Modified: 2012-11-05 23:21 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.5.x and above
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
dmesg output from 3.6-rc3 (33.22 KB, text/plain)
2012-08-31 10:20 UTC, Sudaraka Wijesinghe
Details
xrandr output from 3.4.9 where everything works fine (9.81 KB, text/plain)
2012-08-31 10:20 UTC, Sudaraka Wijesinghe
Details
lspci output (10.70 KB, text/plain)
2012-08-31 10:21 UTC, Sudaraka Wijesinghe
Details
dmesg output from 3.4.9 with drm-debug=0xe where monitor gets a signal (49.47 KB, text/plain)
2012-08-31 16:46 UTC, Sudaraka Wijesinghe
Details
dmesg output from 3.6-rc3 with drm-debug=0xe where monitor is not getting a signal (62.45 KB, text/plain)
2012-08-31 16:47 UTC, Sudaraka Wijesinghe
Details
fix-up revert (2.09 KB, patch)
2012-09-01 21:49 UTC, Daniel Vetter
Details | Diff
intel_infoframes output when no signal on monitor (1.14 KB, text/plain)
2012-09-04 13:53 UTC, Sudaraka Wijesinghe
Details
intel_infoframes-linux-3.5.3-with-4e89ee-commit.txt (1.14 KB, text/plain)
2012-09-04 13:54 UTC, Sudaraka Wijesinghe
Details
intel_infoframes-linux-3.5.3-without-4e89ee-commit.txt (1.13 KB, text/plain)
2012-09-04 13:54 UTC, Sudaraka Wijesinghe
Details
intel_infoframes output right after booting into "bad kernel" (1.14 KB, text/plain)
2012-09-16 22:21 UTC, Sudaraka Wijesinghe
Details
intel_infoframes output right after running 'VIC 0' command (1.14 KB, text/plain)
2012-09-16 22:22 UTC, Sudaraka Wijesinghe
Details
Fix attempt and debug info (1.64 KB, patch)
2012-09-19 20:15 UTC, Paulo Zanoni
Details | Diff
dmesg with patch from comment #35 (34.39 KB, text/plain)
2012-09-20 17:54 UTC, Sudaraka Wijesinghe
Details
Final patch 1/2 (1.04 KB, patch)
2012-09-20 22:32 UTC, Paulo Zanoni
Details | Diff
Final patch 2/2 (2.24 KB, patch)
2012-09-20 22:36 UTC, Paulo Zanoni
Details | Diff

Description Sudaraka Wijesinghe 2012-08-31 10:20:00 UTC
Created attachment 78871 [details]
dmesg output from 3.6-rc3

I use an external monitor connected to my laptop via HDMI and it has
been working fine until recently I upgraded to Kernel 3.5 (also affected in all 3.5.x and 3.6-rcx).

I get a "no signal" message on the monitor and it goes to sleep. Display on
the laptop screen is fine only that there is no output on the external
monitor right from the boot.

(Please refer https://lkml.org/lkml/2012/8/10/147)

Attached dmesg is from 3.6-rc3 and the xrandr output is from 3.4.9 where everything is working fine.
Comment 1 Sudaraka Wijesinghe 2012-08-31 10:20:52 UTC
Created attachment 78881 [details]
xrandr output from 3.4.9 where everything works fine
Comment 2 Sudaraka Wijesinghe 2012-08-31 10:21:58 UTC
Created attachment 78891 [details]
lspci output
Comment 3 Daniel Vetter 2012-08-31 15:49:02 UTC
Two things:
- Can you please boot with drm.debug=0xe on both 3.4.x and 3.5.y and attach the full dmesg?
- Can you try to bisect this issue? Knowing the culprit that introduce a problem usually helps enormously in tracking down a regression?
Comment 4 Sudaraka Wijesinghe 2012-08-31 16:46:27 UTC
Created attachment 78941 [details]
dmesg output from 3.4.9 with drm-debug=0xe where monitor gets a signal
Comment 5 Sudaraka Wijesinghe 2012-08-31 16:47:22 UTC
Created attachment 78951 [details]
dmesg output from 3.6-rc3 with drm-debug=0xe where monitor is not getting a signal
Comment 6 Sudaraka Wijesinghe 2012-08-31 16:50:52 UTC
Daniel,

I have attached the two dmesg outputs as you asked.

For the bisect thing, I will need more assistance on how to do it. I'm using the source downloaded from kernel.org, do I need to switch to using git version? (which is fine)

Thanks.
Comment 7 Daniel Vetter 2012-08-31 17:37:58 UTC
> --- Comment #6 from Sudaraka Wijesinghe <sudaraka.wijesinghe@gmail.com> 
> 2012-08-31 16:50:52 ---
> Daniel,
>
> I have attached the two dmesg outputs as you asked.
>
> For the bisect thing, I will need more assistance on how to do it. I'm using
> the source downloaded from kernel.org, do I need to switch to using git
> version? (which is fine)

Yes. See http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/
for a nice howto.
Comment 8 Sudaraka Wijesinghe 2012-08-31 23:44:52 UTC
Thank you for the info. Here is the bisect result

  dc257cf154be708ecc47b8b89c12ad8cd2cc35e4 is the first bad commit
Comment 9 Daniel Vetter 2012-09-01 09:30:37 UTC
Hm, that's strange that you've hit this merge commit. Can you pls double-check whether the two immediate parents really both work? You can check them out from your git repo with

$ git checkout 5bc69bf

and

$ git checkout d48b97b

Maybe also double-check that dc257cf154be708ecc47b8b89c12ad8cd2cc35e4 really is bad.

If this is indeed the case, we're pretty much back to square one :( The merge doesn't touch the hdmi support, and hence would only inflict a timing change.
Comment 10 Sudaraka Wijesinghe 2012-09-01 20:21:05 UTC
It's possible that I might have taken a wrong turn in the first bisect, during which I hit the commit b3daeaef559d87b974c13a096582c5c70dc11061 where output was fine via HDMI but the output on laptop screen was messed up, pixels were like out of sync with each other.

First time I marked this as bad and ended up with the commit I mentioned above. This time I marked it as good (since output on the external monitor was fine) and goto the commit 64172ccbe22ad85f9e6ac7ec47af2a350f00e0da.

When building at this commit, I get a build error which seems to be from a unrelated modules but keeps me from continuing.

  ERROR: "set_personality_ia32" [arch/x86/ia32/ia32_aout.ko] undefined!
  make[1]: *** [__modpost] Error 1
  make: *** [modules] Error 2
Comment 11 Daniel Vetter 2012-09-01 20:27:08 UTC
> --- Comment #10 from Sudaraka Wijesinghe <sudaraka.wijesinghe@gmail.com> 
> 2012-09-01 20:21:05 ---
> It's possible that I might have taken a wrong turn in the first bisect,
> during
> which I hit the commit b3daeaef559d87b974c13a096582c5c70dc11061 where output
> was fine via HDMI but the output on laptop screen was messed up, pixels were
> like out of sync with each other.

Yeah, if you do larger bisects it sometimes happens that other issues
(like this one or the compile issue below) get in the way. It's
important that you ignore these as much as possible. If disabling
other modules (like below) or ignoring unrelated issues isn't
possible, you can tell git bisect that you can't test this commit with

$ git bisect skip

git will then look for another commit to test.

> First time I marked this as bad and ended up with the commit I mentioned
> above.
> This time I marked it as good (since output on the external monitor was fine)
> and goto the commit 64172ccbe22ad85f9e6ac7ec47af2a350f00e0da.
>
> When building at this commit, I get a build error which seems to be from a
> unrelated modules but keeps me from continuing.
>
>   ERROR: "set_personality_ia32" [arch/x86/ia32/ia32_aout.ko] undefined!
>   make[1]: *** [__modpost] Error 1
>   make: *** [modules] Error 2

You can work around this specific issue by disable a.out support
(which you very likely don't need - it's backwards compat stuff for
~15 year old binaries ...). Just disable CONFIG_BINFMT_AOUT.
Comment 12 Sudaraka Wijesinghe 2012-09-01 21:27:46 UTC
Thanks for the info, I hope the following info will be useful. This is the bad commit I got from the bisect.

4e89ee174bb2da341bf90a84321c7008a3c9210d is the first bad commit
commit 4e89ee174bb2da341bf90a84321c7008a3c9210d
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri May 4 17:18:26 2012 -0300

    drm/i915: set the DIP port on ibx_write_infoframe
    
    Just like Gen 4, IBX has a "Port Select" field on the DIP register,
    but the ports are different.
    
    Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

:040000 040000 dbe82f98dd2286daa19238da4d5a025962fcfc60 431089b262fa4b2e7fb4ad673e0b264285227597 M	drivers
Comment 13 Daniel Vetter 2012-09-01 21:49:51 UTC
Created attachment 78981 [details]
fix-up revert

Yeah, that commit makes much more sense. To double-check, can you please test whether the attached manual revert (there was a small conflict) applied on top of 3.5 makes hdmi work for you again?
Comment 14 Sudaraka Wijesinghe 2012-09-01 23:07:45 UTC
yes, hdmi works with 3.5.y after applying that patch.
Comment 15 Paulo Zanoni 2012-09-03 21:16:00 UTC
Reassigning the bug to me since I'm the author of the "regression".

1 - Is this an HDMI or DVI monitor? Is your laptop port an HDMI port or a DVI port? Is there any kind of HDMI/DVI converter/adaptor being used? Any man-in-the-middle devices between the monitor and the computer?

2 - After booting the "bad kernel", is there any difference if you turn your monitor off and then on?

3 - Please download and compile intel-gpu-tools (http://cgit.freedesktop.org/xorg/app/intel-gpu-tools).

4 - Please boot the "bad kernel", then run "sudo ./tools/intel_infoframes -d". Please paste the output here.

5 - Then run "sudo ./tools/intel_infoframes -t A -x -t B -x". Then turn the monitor off, then turn the monitor on. Does it solve anything?

6 - Since you already have the "good kernel" compiled (with Daniel's patch), can you please also boot it, run "sudo ./intel_infoframes -d" and paste the output here?

It smells like maybe your monitor does not like/want infoframes. It took me many hours to make infoframes work :)
Comment 16 Sudaraka Wijesinghe 2012-09-04 13:46:02 UTC
> 1 - Is this an HDMI or DVI monitor? Is your laptop port an HDMI port or a DVI
> port? Is there any kind of HDMI/DVI converter/adaptor being used? Any
> man-in-the-middle devices between the monitor and the computer?
> 
Monitor supports all HDMI, DVI and VGA. But in this case it connected
directly to my laptop HDMI port via cable (no intermediate devices).
(My monitor is a Acer S240HL Abid, if the specifics help)

> 2 - After booting the "bad kernel", is there any difference if you turn your
> monitor off and then on?
> 
Tried this with no luck.

> 4 - Please boot the "bad kernel", then run "sudo ./tools/intel_infoframes
> -d".
> Please paste the output here.
> 
Please see the attached intel_infoframes-linux-3.5.3-with-4e89ee-commit.txt

> 5 - Then run "sudo ./tools/intel_infoframes -t A -x -t B -x". Then turn the
> monitor off, then turn the monitor on. Does it solve anything?
> 
Yes, Once I ran this display came on the monitor (without turning it off
and on again)

> 6 - Since you already have the "good kernel" compiled (with Daniel's patch),
> can you please also boot it, run "sudo ./intel_infoframes -d" and paste the
> output here?
> 
Please see the attached
intel_infoframes-linux-3.5.3-without-4e89ee-commit.txt

> It smells like maybe your monitor does not like/want infoframes. It took me
> many hours to make infoframes work :)
> 
Appreciate all your work, hope we can get this resolved soon.

Thanks.
Comment 17 Sudaraka Wijesinghe 2012-09-04 13:53:47 UTC
Created attachment 79241 [details]
intel_infoframes output when no signal on monitor
Comment 18 Sudaraka Wijesinghe 2012-09-04 13:54:33 UTC
Created attachment 79251 [details]
intel_infoframes-linux-3.5.3-with-4e89ee-commit.txt
Comment 19 Sudaraka Wijesinghe 2012-09-04 13:54:55 UTC
Created attachment 79261 [details]
intel_infoframes-linux-3.5.3-without-4e89ee-commit.txt
Comment 20 Paulo Zanoni 2012-09-04 17:14:18 UTC
So, if I understood things correctly, basically it seems your monitor does not like HDMI infoframes. And this creates a problem, because as far as we have checked, in some use cases we are required to send Infoframes and in your case we are required not to send them :(

An idea would be to check if by sending extra Infoframe information your monitor would actually start working, but this requires some time playing with the intel_infoframes tool in your specific monitor, which I don't have.

Another idea is to check if there's something in the EDID saying "please don't send infoframes". A quick check yesterday did not show anything.

If we just revert the patch we'll have other users reporting that the "revert" is causing them problems because now there are no infoframes and so they get black screens :(
Comment 21 Sudaraka Wijesinghe 2012-09-04 18:23:34 UTC
> An idea would be to check if by sending extra Infoframe information your
> monitor would actually start working, but this requires some time playing
> with
> the intel_infoframes tool in your specific monitor, which I don't have.
> 
I understand, will it be possible for me to attempt to do this, given
that I have no idea what infoframes are? (I don't mind reading some
documentation if that can be done in that way)


> If we just revert the patch we'll have other users reporting that the
> "revert"
> is causing them problems because now there are no infoframes and so they get
> black screens :(
> 
I agree, I also haven't met anyone having the same problem in any of the
forums I posted about this issue, so I don't think reverting is an option.
However, can we have a config parameter to stop sending the infoframes
so people like me can turn it off? or is that too much trouble for nothing?
Comment 22 Paulo Zanoni 2012-09-04 18:38:16 UTC
(In reply to comment #21)
> > An idea would be to check if by sending extra Infoframe information your
> > monitor would actually start working, but this requires some time playing
> with
> > the intel_infoframes tool in your specific monitor, which I don't have.
> > 
> I understand, will it be possible for me to attempt to do this, given
> that I have no idea what infoframes are? (I don't mind reading some
> documentation if that can be done in that way)
> 

It would be necessary to read the CEA-861 and the HDMI specifications, but they cost money to obtain.

> 
> > If we just revert the patch we'll have other users reporting that the
> "revert"
> > is causing them problems because now there are no infoframes and so they
> get
> > black screens :(
> > 
> I agree, I also haven't met anyone having the same problem in any of the
> forums I posted about this issue, so I don't think reverting is an option.
> However, can we have a config parameter to stop sending the infoframes
> so people like me can turn it off? or is that too much trouble for nothing?

Having a parameter wouldn't prevent the black screens. First you get a black screen and then you learn about the parameter and use it. We should work on a solution that allows us to automagically decide whether we want or not to send infoframes. The parameter should be really the last thing to attempt.

Testing the same machine on different monitors and the same monitor on different machines would also help.
Comment 23 Daniel Vetter 2012-09-10 15:03:26 UTC
Can you please test the patch at

https://patchwork.kernel.org/patch/1386831/

Thanks, Daniel
Comment 24 Sudaraka Wijesinghe 2012-09-11 00:26:59 UTC
> Can you please test the patch at
> 
> https://patchwork.kernel.org/patch/1386831/

This patch did not solve the issue.

I did reverse the last patch you gave me before applying this. I hope
that's the correct way to do it?
Comment 25 Paulo Zanoni 2012-09-14 22:04:06 UTC
On the "bad kernel", *none* of the modes work?

Please boot the machine on the bad Kernel, then use xrandr to try to switch between the different modes. Do all modes give you a black screen?

Thanks,
Paulo
Comment 26 Paulo Zanoni 2012-09-14 22:19:23 UTC
Another test:

Boot the "bad Kernel", then put your monitor on the native 1920x1080 mode (the one that should be the default), then run:

  sudo ./intel_infoframes -t B -f AVI -c 'VIC 16'

Does it work?

After this, please run:

  sudo ./intel_infoframes -t B -f SPD -n

Does it work?

Then:

  sudo ./intel_infoframes -t B -f AVI -c 'ITC 1'

Does it work?

Then:

  sudo ./intel_infoframes -t B -f AVI -n

Does it work?

Thanks,
Paulo
Comment 27 Sudaraka Wijesinghe 2012-09-15 03:50:59 UTC
> Please boot the machine on the bad Kernel, then use xrandr to try to switch
> between the different modes. Do all modes give you a black screen?
> 
Yes, all modes get the blank screen.
Comment 28 Sudaraka Wijesinghe 2012-09-15 03:51:33 UTC
> Boot the "bad Kernel", then put your monitor on the native 1920x1080 mode
> (the
> one that should be the default), then run:
> 
>   sudo ./intel_infoframes -t B -f AVI -c 'VIC 16'
> 
This Works (monitor turns on)

> After this, please run:
> 
>   sudo ./intel_infoframes -t B -f SPD -n
> 
This keeps the monitor on the same condition (working) from above

> Then:
> 
>   sudo ./intel_infoframes -t B -f AVI -c 'ITC 1'
> 
This keeps the monitor on the same condition (working) from above

> 
> Then:
> 
>   sudo ./intel_infoframes -t B -f AVI -n
> 
This keeps the monitor on the same condition (working) from above
Comment 29 Paulo Zanoni 2012-09-15 19:45:54 UTC
(In reply to comment #28)
> > Boot the "bad Kernel", then put your monitor on the native 1920x1080 mode
> (the
> > one that should be the default), then run:
> > 
> >   sudo ./intel_infoframes -t B -f AVI -c 'VIC 16'
> > 
> This Works (monitor turns on)
> 

This is interesting news :)

So previously we discovered that if we turn off the infoframes your monitor would work. Now we discovered that if we set the VIC field of the AVI infoframe to non-zero your monitor works. Your monitor is the first one I see requiring the VIC to be non-zero, so I'll ask for some more tests just to confirm.

So, after you set the VIC to 16 that, can you please run these commands and tell me what happens after each of them?

  sudo ./intel_infoframes -t B -f AVI -c 'VIC 0'
  sudo ./intel_infoframes -t B -f AVI -c 'VIC 1'
  sudo ./intel_infoframes -t B -f AVI -c 'VIC 15'
  sudo ./intel_infoframes -t B -f AVI -c 'VIC 16'

(you can also play with other values if you want... feel free)

So basically the CEA-861 specification defines dozens of modes and they give each mode a VIC (Video Identification Code), which is basically an ID for the mode. The spec says that if you're using one of the modes provided by the CEA-861 spec you "shall" (mandatory) to set its VIC on the VIC field of the AVI Infoframe. But the spec says that if you set the VIC to 0 it means you're using any other mode not specified by the CEA-861 spec. So far, all monitors we saw work by setting VIC always to 0. It also seems that your xrandr shows some modes that are not defined by the CEA-861, I wonder why they don't work when we set VIC to 0.

So basically what we need to do to at least fix some of your modes is to write code that correctly sets the VIC value according to the spec.

> > After this, please run:
> > 
> >   sudo ./intel_infoframes -t B -f SPD -n
> > 
> This keeps the monitor on the same condition (working) from above
> 

Oh, I was not exactly expecting the last command to work. So, what happens if you're on the "bad state" and run this?

> > Then:
> > 
> >   sudo ./intel_infoframes -t B -f AVI -c 'ITC 1'
> > 
> This keeps the monitor on the same condition (working) from above
> 
> > 
> > Then:
> > 
> >   sudo ./intel_infoframes -t B -f AVI -n
> > 
> This keeps the monitor on the same condition (working) from above
Comment 30 Sudaraka Wijesinghe 2012-09-16 13:10:07 UTC
> --- Comment #29 from Paulo Zanoni <przanoni@gmail.com>  2012-09-15 19:45:54
> ---
> (In reply to comment #28)
>>> Boot the "bad Kernel", then put your monitor on the native 1920x1080 mode
>>> (the
>>> one that should be the default), then run:
>>>
>>>   sudo ./intel_infoframes -t B -f AVI -c 'VIC 16'
>>>
>> This Works (monitor turns on)
>>
> 
> This is interesting news :)
> 
> So previously we discovered that if we turn off the infoframes your monitor
> would work. Now we discovered that if we set the VIC field of the AVI
> infoframe
> to non-zero your monitor works. Your monitor is the first one I see requiring
> the VIC to be non-zero, so I'll ask for some more tests just to confirm.
> 
> So, after you set the VIC to 16 that, can you please run these commands and
> tell me what happens after each of them?
> 
>   sudo ./intel_infoframes -t B -f AVI -c 'VIC 0'
>   sudo ./intel_infoframes -t B -f AVI -c 'VIC 1'
>   sudo ./intel_infoframes -t B -f AVI -c 'VIC 15'
>   sudo ./intel_infoframes -t B -f AVI -c 'VIC 16'
> 
> (you can also play with other values if you want... feel free)
> 
> So basically the CEA-861 specification defines dozens of modes and they give
> each mode a VIC (Video Identification Code), which is basically an ID for the
> mode. The spec says that if you're using one of the modes provided by the
> CEA-861 spec you "shall" (mandatory) to set its VIC on the VIC field of the
> AVI
> Infoframe. But the spec says that if you set the VIC to 0 it means you're
> using
> any other mode not specified by the CEA-861 spec. So far, all monitors we saw
> work by setting VIC always to 0. It also seems that your xrandr shows some
> modes that are not defined by the CEA-861, I wonder why they don't work when
> we
> set VIC to 0.
> 
> So basically what we need to do to at least fix some of your modes is to
> write
> code that correctly sets the VIC value according to the spec.
> 

I ran above command with different random values for VIC between 0 and
79 and monitor turned on for all of them (Including VIC 0).
I checked the value of VIC after booting with the "bad kernel" (while
monitor shows no signal) and it was 0, setting the VIC to 0 again with
the command above turned the monitor on. I don't know if this means
anything but feels wired to me.

Also, I noticed that even with the "bad kernel" after I "fix" the
monitor with the command above (or ones that work below) rebooting the
laptop still keeps the monitor in good state. It goes to the bad state
after I turn the laptop off and on again.

>>> After this, please run:
>>>
>>>   sudo ./intel_infoframes -t B -f SPD -n
>>>
>> This keeps the monitor on the same condition (working) from above
>>
> 
> Oh, I was not exactly expecting the last command to work. So, what happens if
> you're on the "bad state" and run this?
> 

You were right about this, when I ran this command while the monitor is
in the bad state it did not changed anything.

>>> Then:
>>>
>>>   sudo ./intel_infoframes -t B -f AVI -c 'ITC 1'
>>>
>> This keeps the monitor on the same condition (working) from above
>>
>>>
>>> Then:
>>>
>>>   sudo ./intel_infoframes -t B -f AVI -n
>>>
>> This keeps the monitor on the same condition (working) from above
> 

Both above command also worked when I ran them while monitor is in the
bad state.
Comment 31 Paulo Zanoni 2012-09-16 21:52:19 UTC
Oh, maybe I was wrong in comment #29. This time your bug looks more like the bugs I saw in the past :)

What I saw in the past was that just running "intel_infoframes -d" would make things work. So in your case, as far as I understood, just running it won't help, but setting some value of the AVI infoframe (even if it's a value that's already being used) will solve it.

So a final question just to confirm:

After booting on the "bad state", running

  sudo ./intel_infoframes -d

*won't* make the monitor work, but running:

  sudo ./intel_infoframes -t B -f AVI -c 'VIC 0'

will make it work?

If I'm right, please save the output of the first "intel_infoframes -d" (on a bad state), then after the second command (where you set VIC to 0) can you please run "intel_infoframes -d" again and attach it here?

Thanks a lot for your help! Having bug reporters like you makes debugging much more fun and easier :)
Comment 32 Sudaraka Wijesinghe 2012-09-16 22:21:22 UTC
Created attachment 80321 [details]
intel_infoframes output right after booting into "bad kernel"
Comment 33 Sudaraka Wijesinghe 2012-09-16 22:22:09 UTC
Created attachment 80331 [details]
intel_infoframes output right after running 'VIC 0' command
Comment 34 Sudaraka Wijesinghe 2012-09-16 22:31:44 UTC
> After booting on the "bad state", running
> 
>   sudo ./intel_infoframes -d
> 
Attached: https://bugzilla.kernel.org/attachment.cgi?id=80321

> *won't* make the monitor work, but running:
> 
>   sudo ./intel_infoframes -t B -f AVI -c 'VIC 0'
> 
Attached: https://bugzilla.kernel.org/attachment.cgi?id=80331

> will make it work?
> 
> If I'm right, please save the output of the first "intel_infoframes -d" (on a
> bad state), then after the second command (where you set VIC to 0) can you
> please run "intel_infoframes -d" again and attach it here?
> 

Yes, I can confirm this, every time I run intel_infoframes with VIC
parameter (even if it has the current value) monitor turns on from it's
"no signal" state.

> Thanks a lot for your help! Having bug reporters like you makes debugging
> much
> more fun and easier :)
> 
You are welcome, I'm glad to help out and it also gave me a change to
learn few tricks :)
And, Thank you both Paulo and Daniel for your time effort in solving my
issue and guiding me though the process so I could provide you with the
information you need.
Comment 35 Paulo Zanoni 2012-09-19 20:15:22 UTC
Created attachment 80591 [details]
Fix attempt and debug info

Can you please try this patch? It should apply against Torvald's 3.6 tree.

Ok, so here are the current theories:
- By looking at the diff between the attachments in comments #32 and #33 it seems that for some reason your ECC is wrong and your monitor does not like the wrong ECC, which makes sense.
- The ECC is generated by the Hardware and should be read-only, so it's not like we are setting the wrong ECC value.
- On my computer (where infoframes are supposed to work), when I dump the infoframes, byte 0 is e40d0282 and byte 8 is 0000005f, which matches attachment 80331 [details] from comment #33, which should be correct
- From the fact that running 'intel_infoframes -d' does not fix your problem but running 'intel_infoframes -t B -f AVI -c 'VIC 0' does solve your problem, it seems there's a difference between the implementation of intel_infoframes and the implementation in the Kernel

So this patch tries to do a few things:
- Add some debug messages
- Make sure you're not leaving the function on the "default" case
- Write 8 infoframe bytes instead of "only the necessary". This is what the intel_infoframes tool does, and maybe it is needed in order to generate the correct ECC value?

Can you please boot this patch with drm.debug=0xe and attach the dmesg? Let's hope this works..
Comment 36 Sudaraka Wijesinghe 2012-09-20 17:54:51 UTC
Created attachment 80651 [details]
dmesg with patch from comment #35
Comment 37 Sudaraka Wijesinghe 2012-09-20 17:57:44 UTC
dmesg out put attached.
https://bugzilla.kernel.org/attachment.cgi?id=80651

Monitor is working when I boot with this patch.
Comment 38 Paulo Zanoni 2012-09-20 22:32:36 UTC
Created attachment 80661 [details]
Final patch 1/2
Comment 39 Paulo Zanoni 2012-09-20 22:36:59 UTC
Created attachment 80671 [details]
Final patch 2/2

Hi

Can you please remove any patches you may have previously applied and then apply these 2 patches to the 3.6 tree and test them?

These are the patches I plan to send to the official Kernel trees, so having them tested by you is the final step.

Thank you for your patience and your help!
Paulo
Comment 40 Sudaraka Wijesinghe 2012-09-21 21:03:19 UTC
Yes, this patch solves the issue I had with my monitor.

Thank you.
Comment 41 Sudaraka Wijesinghe 2012-10-13 12:33:36 UTC
Marking this bug as Resolved as the fix/patch is now available in the 3.6.2 stable kernel.

Thanks Paulo, Daniel and others.
Comment 42 Florian Mickler 2012-10-15 21:29:34 UTC
A patch referencing this bug report has been merged in Linux v3.7-rc1:

commit adf00b26d18e1b3570451296e03bcb20e4798cdd
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Tue Sep 25 13:23:34 2012 -0300

    drm/i915: make sure we write all the DIP data bytes
Comment 43 Florian Mickler 2012-11-05 23:21:23 UTC
A patch referencing a commit referencing this bug report has been merged in Linux v3.7-rc4:

commit b6e0e543f75729f207b9c72b0162ae61170635b2
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Oct 21 12:52:39 2012 +0200

    drm/i915: clear the entire sdvo infoframe buffer

Note You need to log in before you can comment on or make changes to this bug.