Bug 77648

In a similar case with DP connected, if a VGA display *is* connected too and you specify its "mode=off" in weston.ini... we still encounter this issue.

I tried to reproduce this with the latest Tizen IVI image I found here [1], which as of today is tizen_20140410.3_ivi-efi-i586-sdb.raw.bz2. I tested it on a VTC 1010, but I didn't see the bug. The DP output was rendering properly on both cases, with VGA enabled or disable.

Do you have anything interesting in dmesg when you see the bug?


[1] http://download.tizen.org/snapshots/tizen/ivi/ivi/latest/images/ivi-efi-i586/

(In reply to comment #2)
> I tried to reproduce this with the latest Tizen IVI image I found here [1],
> which as of today is tizen_20140410.3_ivi-efi-i586-sdb.raw.bz2. I tested it
> on a VTC 1010, but I didn't see the bug. The DP output was rendering
> properly on both cases, with VGA enabled or disable.
> 
> Do you have anything interesting in dmesg when you see the bug?
> 
> 
> [1]
> http://download.tizen.org/snapshots/tizen/ivi/ivi/latest/images/ivi-efi-i586/

I forgot to mention that I tested and reproduced this with Fedora 20 and updated kernel package (3.13.9ish) installed on the VTC 1010.

Perhaps tizen recently patched/updated something that fixed it for them??

I'll do more investigation next time my VTC 1010 is within reach.

(In reply to comment #2)
> I tried to reproduce this with the latest Tizen IVI image I found here [1],
> which as of today is tizen_20140410.3_ivi-efi-i586-sdb.raw.bz2. I tested it
> on a VTC 1010, but I didn't see the bug. The DP output was rendering
> properly on both cases, with VGA enabled or disable.
> 
> Do you have anything interesting in dmesg when you see the bug?
> 
> 
> [1]
> http://download.tizen.org/snapshots/tizen/ivi/ivi/latest/images/ivi-efi-i586/

Ander,
It's possible that the IVI images have appended "video=VGA-1:d" to the kernel command line to workaround this issue.  The point is not to have to do that.  Could you verify that the VGA is not disabled in the kernel before attempting to reproduce?

(In reply to comment #4)
> (In reply to comment #2)
> > I tried to reproduce this with the latest Tizen IVI image I found here [1],
> > which as of today is tizen_20140410.3_ivi-efi-i586-sdb.raw.bz2. I tested it
> > on a VTC 1010, but I didn't see the bug. The DP output was rendering
> > properly on both cases, with VGA enabled or disable.
> > 
> > Do you have anything interesting in dmesg when you see the bug?
> > 
> > 
> > [1]
> > http://download.tizen.org/snapshots/tizen/ivi/ivi/latest/images/ivi-efi-i586/
> 
> Ander,
> It's possible that the IVI images have appended "video=VGA-1:d" to the
> kernel command line to workaround this issue.  The point is not to have to
> do that.  Could you verify that the VGA is not disabled in the kernel before
> attempting to reproduce?

I don't see any occurrence of video=VGA-1:d in the loader config. Moreover, I did test with VGA enabled in which case I got image on both outputs. This is what I have:

boot/loader/loader.conf:

# Generated by setup-gummiboot-conf
timeout 0
default vmlinuz-3.13.3-17.2-x86-ivi

boot/loader/entries/vmlinuz-3.13.3-17.2-x86-ivi.conf:

# Generated by setup-gummiboot-conf
title Tizen 3.0.0 (Tizen Next)
version 3.13.3-17.2-x86-ivi
efi /vmlinuz-3.13.3-17.2-x86-ivi
options rootwait rootfstype=ext4 quiet root=PARTUUID=23DADB8A-B065-480E-8BFC-94D7548D5B52


I wonder if this could be a link training issue with a specific monitor. I only tested with the monitor I have on my desk.

Yup, dmesg prints a few errors:

Apr 24 01:41:49 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up
Apr 24 01:41:49 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up
Apr 24 01:41:50 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up
Apr 24 01:41:50 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up
Apr 24 01:41:51 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up
Apr 24 01:41:51 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up
Apr 24 01:41:52 BYT-I-VTC1010-1 kernel: [drm:intel_dp_start_link_train] *ERROR* too many full retries, give up
Apr 24 01:41:52 BYT-I-VTC1010-1 kernel: [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting

I am using an Active HDMI->DisplayPort adapter to connect my monitor.
I tried a DELL S2240T and a Giantec 11.6" Touchscreen monitor.

Artie, I believe this would be a drm driver issue, so I'm reassigning it. I believe they'll want the full output of dmesg with the kernel booted with drm.debug=0x06 in the kernel command line.


Summary of the previous comments:

On a VTC 1010 device (BayTrail based), no image is displayed on a monitor connected to a DisplayPort with an active HDMI->DisplayPort adapater. Tested with Fedora 20 and "updated kernel package (3.13.9ish)".

I don't know if you have any backported commits in your kernel, but there's plenty of BYT DP related fixes we've added lately. Please try the drm-intel-nightly branch of [1], and attach dmesg with drm.debug=0xe module parameter. Thanks.

[1] http://cgit.freedesktop.org/drm-intel

(In reply to comment #7)
> Artie, I believe this would be a drm driver issue, so I'm reassigning it. I
> believe they'll want the full output of dmesg with the kernel booted with
> drm.debug=0x06 in the kernel command line.
> 
> 

I agree with your conclusion... thanks for recategorizing.

> Summary of the previous comments:
> 
> On a VTC 1010 device (BayTrail based), no image is displayed on a monitor
> connected to a DisplayPort with an active HDMI->DisplayPort adapater. Tested
> with Fedora 20 and "updated kernel package (3.13.9ish)".

I would also add that, this only happens when VGA is disabled at startup.

(In reply to comment #8)
> I don't know if you have any backported commits in your kernel, but there's
> plenty of BYT DP related fixes we've added lately. Please try the
> drm-intel-nightly branch of [1], and attach dmesg with drm.debug=0xe module
> parameter. Thanks.
> 
> [1] http://cgit.freedesktop.org/drm-intel

The kernel I'm using is a pristine release from Fedora updates... I'll try the drm-intel-nightly and report back.

Created attachment 98130 [details]
drm-intel-nightly 11ddb59 - dmesg

dmesg output with drm.debug=0xe using drm-intel-nightly 11ddb59.

It does not seems like a highest/Critical Bug, downgrade to high/major severity.

Which active DP->HDMI adapter are you using? Is this still happening with the latest -nightly? I have a VTC1010 here that I can investigate this on. I'll source the same active adapter and see about reproducing this problem.

-T

(In reply to comment #13)
> Which active DP->HDMI adapter are you using? Is this still happening with
> the latest -nightly? I have a VTC1010 here that I can investigate this on.
> I'll source the same active adapter and see about reproducing this problem.
> 
> -T

I tested with a StarTech DisplayPort to HDMI Active Adapter DP2HDS.  I have not tested against -nightly for a few months, so not sure if it's still an issue there... I'll try to carve some time aside this week to see if it's still reproducible with latest -nightly.

(In reply to comment #14)
> (In reply to comment #13)
> > Which active DP->HDMI adapter are you using? Is this still happening with
> > the latest -nightly? I have a VTC1010 here that I can investigate this on.
> > I'll source the same active adapter and see about reproducing this problem.
> > 
> > -T
> 
> I tested with a StarTech DisplayPort to HDMI Active Adapter DP2HDS.  I have
> not tested against -nightly for a few months, so not sure if it's still an
> issue there... I'll try to carve some time aside this week to see if it's
> still reproducible with latest -nightly.

Tested again with drm-intel-nightly 778206252.  I can no longer reproduce this issue.

Furthermore, I couldn't reproduce on a more recent F20 kernel (3.14.5) either.

Closing.