Bug 106596

(In reply to genpur from comment #0)
> Created attachment 139667 [details]
> logs : dmesg, xrandr,  Xorg.0.log

Please attach each one individually as plain text. Please add drm.debug=14 and capture dmesg from boot to the problem on the latest kernel you can get your hands on, for the case 01 you describe.

Does it make a difference if the system is booted with the cable connected/disconnected? Please try unplug/plug and have that included in the dmesg.

Created attachment 139721 [details]
dmesg_case01_adapter_connected_on_the_beginning

Created attachment 139722 [details]
dmesg_case01_adapter_disconnected_on_the_beggining

I added both dmesg logs - system started with adapter(and DVI cable) connected to external monitor and system started with adapter disconnected. For both cases I have plugged/unplugged adapter few times. It's registered in dmesg.
I don't know is it something strange/important for you, but I saw that connecting and disconnecting only the cable (which connects adapter with monitor) when adapter is connected of course, does nothing even dmesg does not register any action.

From logs

[    1.854035] [drm:intel_dp_detect [i915]] [CONNECTOR:63:DP-1]
[    1.854896] [drm:intel_dp_read_dpcd [i915]] DPCD: 11 0a 82 01 01 05 01 81 00 01 04 01 0f 00 00
[    1.855591] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:63:DP-1] status updated from unknown to disconnected
[    1.855595] [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:63:DP-1] disconnected

we can read the DPCD but we decide nothing's there after all.

Would be great to be able to get the sink count from the dongle. Do you have CONFIG_DRM_DP_AUX_CHARDEV=y? i.e. do you have /dev/drm_dp_auxN devices, N is 0-based number?

What does this output:

# dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200)) count=1 | od -tx1

Cc: Ville

Kernel (4.16.10) has been built with "CONFIG_DRM_DP_AUX_CHARDEV=y" configuration.
Additionally I have also checked few kernels from 4.4 up to 4.16 and all of them have been built with this configuration.

Device /dev/drm_dp_aux0 exists in my system :
LC_MESSAGES=en_UK.UTF-8 ls -lah /dev/drm_dp_aux*
crw------- 1 root root 243, 0 May 24  2018 /dev/drm_dp_aux0


When adapter is disconnected :
LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200)) count=1 | od -tx1
dd: error reading '/dev/drm_dp_aux0': Connection timed out
0+0 records in
0+0 records out
0 bytes copied, 0.0804776 s, 0.0 kB/s
0000000

When adapter is connected :
LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200)) count=1 | od -tx1
1+0 records in
1+0 records out
1 byte copied, 0.000779381 s, 1.3 kB/s
0000000 00
0000001


Another info for you :
I have discovered that when system is started with kernel <= 4.10 with kernel parameter "video=DP-1:D" then it doesn't matter if adapter was plugged or unplugged while booting. External monitor is activated anytime adapter is plugged to the laptop. All the resolutions/refresh rates are available according to technical specification of the monitor, so EDID seems to be read corectly and seems to be not corrupted.
In this case the command "dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200)) count=1 | od -tx1" also returns "00".

Not exactly dupe, but possibly the same fix would cover this bug and bug 106291.

(In reply to genpur from comment #7)
> When adapter is disconnected :
> LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200))
> count=1 | od -tx1
> dd: error reading '/dev/drm_dp_aux0': Connection timed out

As expected.

> When adapter is connected :
> LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200))
> count=1 | od -tx1
> 1+0 records in
> 1+0 records out
> 1 byte copied, 0.000779381 s, 1.3 kB/s
> 0000000 00

That 00 tells us the adapter thinks there are no displays connected to it. That should dynamically change depending on the display being plugged/unplugged into the other end of the cable, and generate a hotplug event. Please double check with a display, and ensure it's on.

How about

dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x80)) count=16 | od -tx1

Ville, perhaps we should only trust sink count if downstream port is hotplug capable, and assume 1 otherwise? Regardless of what the spec says. See the sink count handling in intel_dp_detect_dpcd() - we never reach that if sink count is 0 in intel_dp_get_dpcd(). Not very consistent.

(In reply to Jani Nikula from comment #8)
> Not exactly dupe, but possibly the same fix would cover this bug and bug
> 106291.

Err, not really. But it's related. Maybe. :)

(In reply to Jani Nikula from comment #9)
> (In reply to genpur from comment #7)
> > When adapter is disconnected :
> > LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200))
> > count=1 | od -tx1
> > dd: error reading '/dev/drm_dp_aux0': Connection timed out
> 
> As expected.
> 
> > When adapter is connected :
> > LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200))
> > count=1 | od -tx1
> > 1+0 records in
> > 1+0 records out
> > 1 byte copied, 0.000779381 s, 1.3 kB/s
> > 0000000 00
> 
> That 00 tells us the adapter thinks there are no displays connected to it.
> That should dynamically change depending on the display being
> plugged/unplugged into the other end of the cable, and generate a hotplug
> event. Please double check with a display, and ensure it's on.
> 
> How about
> 
> dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x80)) count=16 | od -tx1
> 
> Ville, perhaps we should only trust sink count if downstream port is hotplug
> capable, and assume 1 otherwise? Regardless of what the spec says. See the
> sink count handling in intel_dp_detect_dpcd() - we never reach that if sink
> count is 0 in intel_dp_get_dpcd(). Not very consistent.

IIRC I was arguing about SINK_COUNT vs. hpd capable years ago with someone. Can't really remember what the issue was though.

Reporter, please attach the full dpcd dump from 'dd if=/dev/drm_dp_aux0' to the bug (should be 1MiB in size, if it comes out short use ddrescue instead). Do make sure the display is powered on and connected to the dongle when you do this.

(In reply to Jani Nikula from comment #9)
> (In reply to genpur from comment #7)
> > When adapter is disconnected :
> > LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200))
> > count=1 | od -tx1
> > dd: error reading '/dev/drm_dp_aux0': Connection timed out
> 
> As expected.
> 
> > When adapter is connected :
> > LC_MESSAGES=en_UK.UTF-8 sudo dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x200))
> > count=1 | od -tx1
> > 1+0 records in
> > 1+0 records out
> > 1 byte copied, 0.000779381 s, 1.3 kB/s
> > 0000000 00
> 
> That 00 tells us the adapter thinks there are no displays connected to it.
> That should dynamically change depending on the display being
> plugged/unplugged into the other end of the cable, and generate a hotplug
> event. Please double check with a display, and ensure it's on.
> 
> How about
> 
> dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x80)) count=16 | od -tx1
> 
> Ville, perhaps we should only trust sink count if downstream port is hotplug
> capable, and assume 1 otherwise? Regardless of what the spec says. See the
> sink count handling in intel_dp_detect_dpcd() - we never reach that if sink
> count is 0 in intel_dp_get_dpcd(). Not very consistent.

dd if=/dev/drm_dp_aux0 bs=1 skip=$((0x80)) count=16 | od -tx1 returns always(*):
0000000 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

(*)always - means for all the cases I have checked when adapter was plugged in to PC and : kernels 4.16, 4.10, monitor undetected or other TV display detected.

Created attachment 139792 [details]
drm_dp_aux0_kernel_4.16.10_adapter_and_monitor_plugged_from_booting

Created attachment 139793 [details]
drm_dp_aux0_kernel_4.16.10_plugged_in_adapter_ONLY

Created attachment 139794 [details]
drm_dp_aux0_kernel_4.16.10_plugged_in_adapter_and_detected_PanasonicTV

Created attachment 139795 [details]
drm_dp_aux0_kernel_4.10.17_adapter_and_detected_monitor_plugged_from_booting_with_param_video_DP-1:D

(In reply to Ville Syrjala from comment #11)
> 
> Reporter, please attach the full dpcd dump from 'dd if=/dev/drm_dp_aux0' to
> the bug (should be 1MiB in size, if it comes out short use ddrescue
> instead). Do make sure the display is powered on and connected to the dongle
> when you do this.

To avoid missunderstanding I want to point attachment under Comment 13 is answer for your request :
https://bugs.freedesktop.org/show_bug.cgi?id=106596#c13

The rest of attachents are extra tests which might be helpful, maybe...
Panasonic TV used here is other display I have checked. TV is detected corectly.

Reporter, do you still have the issue?
Please try to reproduce the issue using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.

Do I have to clone any branch of "drm-tip" via "git clone ..." ? Or maybe download the kernel source, copy some files from cgit.freedesktop.org/drm/drm-tip/ , patch the source files  and proceed full kernel compilation ...? Could you give me some tips how should I use "drm-tip", please? Thank you in advance for help.

(In reply to genpur from comment #19)
> Do I have to clone any branch of "drm-tip" via "git clone ..." ? Or maybe
> download the kernel source, copy some files from
> cgit.freedesktop.org/drm/drm-tip/ , patch the source files  and proceed full
> kernel compilation ...? Could you give me some tips how should I use
> "drm-tip", please? Thank you in advance for help.

Something along these lines:

If you don't have a kernel git repo around then:
git clone git://anongit.freedesktop.org/drm-tip linux
cd linux
git checkout -b your_branch_name origin/drm-tip

Or if you already have one cloned from somewhere else:
cd linux
git remote add drm-tip git://anongit.freedesktop.org/drm-tip
git fetch drm-tip
git checkout -b your_branch_name drm-tip/drm-tip

Reporter, any updates here? Do you still have the issue?
No feedback for more than a month. Dropping the priority to Medium.

I am sorry but since January I work on delegation far away from home. The earliest I will be able to check in the Easter.

> 
> Something along these lines:
> 
> If you don't have a kernel git repo around then:
> git clone git://anongit.freedesktop.org/drm-tip linux
> cd linux
> git checkout -b your_branch_name origin/drm-tip
> 

I have cloned about 2.3GiB of data with commands above. What do I need to do next and how?

Now that you have cloned the latest drm-tip, could you check if this bug can be reproduced?

Manasi

Assessing old bugs, no updates in the last 6 months. Is the problem still there or can we close this? Could you verify with drm tip? If you still need help compiling the kernel please update the bug and we will help.

#assessment

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/119.