Created attachment 49223 [details]
Intel reg dumper output

Created attachment 49224 [details]
Vbiod dump

Created attachment 49225 [details]
Picture with green console

Apart from the absence of drm.debug in that dmesg... I presume you have an SDVO HDMI connection on which we are sending audio because the display says it can handle such, but disagrees.

xrandr --verbose.

With 3.0, xrandr --output HDMI1 --set "audio" "off", should do the trick if I've guessed right.

(In reply to comment #4)
> Apart from the absence of drm.debug in that dmesg... I presume you have an SDVO
> HDMI connection on which we are sending audio because the display says it can
> handle such, but disagrees.
> xrandr --verbose.
> With 3.0, xrandr --output HDMI1 --set "audio" "off", should do the trick if
> I've guessed right.

Well, gave that parameter to kernel as described in http://intellinuxgraphics.org/how_to_report_bug.html. I can try it again in evening.

But cannot understand your "solution".

It works for older kernel, audio and video over the HDMI without any problems. So won't call it a issue with my television advertising audio but not supporting it or has the audio format changed in the new kernels?

And it goes green even in single user mode, without Xorg running. So there is no DISPLAY to xrandr to connect to give you --verbose or set audio off.

Audio enabling on HDMI monitors is one of the paths that has been modified since 2.6.35. Adding a connector property to be able to override audio came much later. (In theory you should be able to disable it through /sys/class/drm/card0-CONNECTOR/ and so not need X). As audio support is enabled by KMS by based on the reported capabilities of the monitor, it affects fbcon equally.

One other patch that catches my eye since v2.6.35 is commit 81a14b46 since that has upset a few people with broken EDID.

Ok, more testing.

I booted up and now got right dmesg. Attaching it and xrandr output next. Booted to Xorg.

Setting audio off does not fix the problem. Screen stays green. But you seem to be awake on IRC, I'll ping you there ;)

Created attachment 49271 [details]
Dmesg output with drm.debug=0x06 (this time it seems to have debug)

Created attachment 49272 [details]
xrandr --verbose

After applying patch that Chris made: http://pastebin.com/iQNNHyVr the result in dmesg with drm.debug=0x06 was multiple lines of:

HDMI connector detected: has_hdmi_monitor=1, has_hdmi_audio=1

So what next?

Just to check, did you try "xrandr --output HDMI1 --set audio off" after applying the debugging patch?

Created attachment 49337 [details]
xrandr --output HDMI1 --set "audio" "off" dmesg output with drm.debug=0x06

No, but now I did and this is the dmesg output of doing it.

Seems to say that has_hdmi_audio=0 so it disables audio, but screen
is still greenish.

Meh.

One last trick before starting afresh, set has_hdmi_monitor=0.

Aren't we supposed to send NULL packets too?

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo
index 30fe554..762d61a 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1061,7 +1061,8 @@ static void intel_sdvo_mode_set(struct drm_encoder *encode
        if (INTEL_INFO(dev)->gen >= 4) {
                sdvox = 0;
                if (intel_sdvo->is_hdmi)
-                       sdvox |= intel_sdvo->color_range;
+                       sdvox |= intel_sdvo->color_range |
+                               NULL_PACKET_VSYNC_ENABLE;
                if (INTEL_INFO(dev)->gen < 5)
                        sdvox |= SDVO_BORDER_ENABLE;
                if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)

There's a patch in https://bugzilla.kernel.org/show_bug.cgi?id=25732 that might also help.

(In reply to comment #15)
> There's a patch in https://bugzilla.kernel.org/show_bug.cgi?id=25732 that might
> also help.

That would make this a duplicate of bug 33760 in this bugzilla as well.

And just to remind myself G35 is gen4... So it looks like we currently do enable NULL_PACKETs but only for the integrated HDMI when audio is enabled. Is that correct or do we need to set the NULL flag for any aviframe (i.e. all HDMI) encoding there as well?

I think we need to set it whenever there's an HDMI sink connected.

It looks like we're calculating the checksum incorrectly too; I think it's just supposed to be for the payload, not for the header bytes.

If you leave the ECC byte in but fix the checksum routine to start the checksum calc at byte 6 instead (past the header and checksum byte) do things work better?

You can just test drm-intel-next from keithp's linux-2.6 tree now, it has the fixes (or what I think are fixes).

Ah, back in business. Had a long vacation trip so didn't follow these up.
Tested with a patch saying intel_svdo->has_hdmi_monitor=0; before that
ickles patch and that made things look normal, but of course the HDMI audio is broken after it.

Ok, will try to figure out, where to get that keithp tree and how i can try to patch it to my kernel.

If there's a .rpm for the kernel somewhere. Ah, seems that Linux 3.1-rc4 has them and that's in rawhide as a prebuild rpm. Will test that now.

Ok. Can confirm that the fixes pushed to Linux 3.1-rc4 fixes my problems. Now the screen is normal and the audio works.

Thanks to everyone! And now to get that fix into Fedora 15 kernel:)

It's back!

kernel-3.4.7-1.fc16.i686
kernel-3.4.9-2.fc16.i686

Are green again and kernel-3.1.8-2.fc16.i686 works.

The first important question is whether the stable 3.5 is equally affected.

Installed kernel-3.5.4-1.fc17.i686.rpm and it works, so it's just Fedora's problem. So closing this again, sorry for the noise:)