Bug 104054 - [SKL][DP] HP Lap Dock external display with DisplayPort over USB Type-C input not properly detected
Summary: [SKL][DP] HP Lap Dock external display with DisplayPort over USB Type-C input...
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: high normal
Assignee: Rodrigo Vivi
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-03 22:18 UTC by Jérôme de Bretagne
Modified: 2019-06-17 19:40 UTC (History)
4 users (show)

See Also:
i915 platform: SKL
i915 features: display/USB-C


Attachments
Output of xrandr --verbose (13.66 KB, text/plain)
2017-12-03 22:20 UTC, Jérôme de Bretagne
no flags Details
edid.bin for the HP Lap Dock external display (256 bytes, application/octet-stream)
2017-12-03 22:22 UTC, Jérôme de Bretagne
no flags Details
Xorg.0.log when starting a session with the external display already plugged, with drm.debug=0x06 (59.01 KB, text/plain)
2017-12-03 22:24 UTC, Jérôme de Bretagne
no flags Details
Xorg.0.log when starting the session without the external display, then plugged in, with drm.debug=0x06 (54.66 KB, text/plain)
2017-12-03 22:25 UTC, Jérôme de Bretagne
no flags Details
dmesg with drm.debug=0x06, with the external display plugged in (125.48 KB, text/plain)
2017-12-03 22:27 UTC, Jérôme de Bretagne
no flags Details
syslog when setting the display to 640x480 with xrandr manually, drm.debug=0x06 (134.61 KB, text/plain)
2017-12-03 22:29 UTC, Jérôme de Bretagne
no flags Details
syslog output when plugging the display during on open X session, with the display ending up rebooting, drm.debug=0x06 (524.01 KB, text/plain)
2017-12-03 22:31 UTC, Jérôme de Bretagne
no flags Details
2nd syslog output when plugging the display during on open X session, with the display ending up rebooting, drm.debug=0x06 (267.31 KB, text/plain)
2017-12-03 22:31 UTC, Jérôme de Bretagne
no flags Details
dmesg with more recent drm-intel-next-2018-02-21 kernel (69.63 KB, text/plain)
2018-03-05 19:36 UTC, Jérôme de Bretagne
no flags Details
kern.log with more recent drm-intel-next-2018-02-21 kernel (105.26 KB, text/plain)
2018-03-05 19:37 UTC, Jérôme de Bretagne
no flags Details
kern.log with more recent drm-intel-next-2018-02-21 kernel and drm_debug=0x1e set (2.89 MB, text/plain)
2018-03-06 12:42 UTC, Jérôme de Bretagne
no flags Details
kern.log with more recent drm-intel-next-2018-02-21 kernel and drm_debug=0x1e set (4.61 MB, text/plain)
2018-03-06 13:02 UTC, Jérôme de Bretagne
no flags Details
dmesg for drm-tip: 2018y-04m-25d-17h-38m-40s UTC and drm.debug=14 (125.14 KB, text/plain)
2018-04-25 22:19 UTC, Jérôme de Bretagne
no flags Details
syslog for drm-tip: 2018y-04m-25d-17h-38m-40s UTC and drm.debug=14 (1.23 MB, text/plain)
2018-04-25 22:55 UTC, Jérôme de Bretagne
no flags Details
kern.log for drm-tip: 2018y-04m-25d-17h-38m-40s UTC and drm.debug=14 (1.03 MB, text/plain)
2018-04-25 23:01 UTC, Jérôme de Bretagne
no flags Details
syslog for linux-4.18.0 with drm.debug=14 (1.45 MB, text/plain)
2018-08-26 10:25 UTC, Jérôme de Bretagne
no flags Details
Xorg.0.log for Linux 4.18.0 with drm.debug=14 (274.83 KB, text/plain)
2018-08-26 10:31 UTC, Jérôme de Bretagne
no flags Details
xrandr --verbose on Linux 4.18.0 with the HP Lap Dock plugged on DP-1 (29.24 KB, text/plain)
2018-08-26 10:42 UTC, Jérôme de Bretagne
no flags Details
kern.log for Linux 4.18.0 with drm.debug=14 (1.21 MB, text/plain)
2018-08-26 10:46 UTC, Jérôme de Bretagne
no flags Details
intel_reg dump - Lap Dock forced in low resolution (26.39 KB, text/plain)
2018-08-28 18:44 UTC, Jérôme de Bretagne
no flags Details
intel_reg dump - Lap Dock plugged but unstable - take 1 (26.42 KB, text/plain)
2018-08-28 18:45 UTC, Jérôme de Bretagne
no flags Details
intel_reg dump - Lap Dock plugged but unstable - take 2 (26.42 KB, text/plain)
2018-08-28 18:45 UTC, Jérôme de Bretagne
no flags Details
intel_reg dump - Lap Dock plugged but unstable - take 3 (26.48 KB, text/plain)
2018-08-28 18:45 UTC, Jérôme de Bretagne
no flags Details
intel_reg dump - Lap Dock plugged but unstable - take 4 (26.41 KB, text/plain)
2018-08-28 18:46 UTC, Jérôme de Bretagne
no flags Details
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock forced in low resolution (4.37 KB, text/plain)
2018-08-28 18:46 UTC, Jérôme de Bretagne
no flags Details
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock plugged but unstable - take 1 (4.38 KB, text/plain)
2018-08-28 18:47 UTC, Jérôme de Bretagne
no flags Details
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock plugged but unstable - take 2 (4.38 KB, text/plain)
2018-08-28 18:48 UTC, Jérôme de Bretagne
no flags Details
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock plugged but unstable - take 3 (4.46 KB, text/plain)
2018-08-28 18:48 UTC, Jérôme de Bretagne
no flags Details
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock plugged but unstable - take 4 (4.38 KB, text/plain)
2018-08-28 18:48 UTC, Jérôme de Bretagne
no flags Details
Experiment 1. Crop link rate to 162000 (870 bytes, patch)
2019-03-05 00:59 UTC, Rodrigo Vivi
no flags Details | Splinter Review
Experiment 2. Crop link rate to 270000 (3.57 KB, patch)
2019-03-05 00:59 UTC, Rodrigo Vivi
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Jérôme de Bretagne 2017-12-03 22:18:08 UTC
-- chipset: Intel HD Graphics 515 (GT2)
-- system architecture: x86_64
-- xserver-xorg-video-intel: 2:2.99.917+git20161206-1
-- xserver-xorg-core: 2:1.19.2-1+deb9u2
-- libdrm-intel1 2.4.74-1
-- kernel version: drm-intel-next-2017-12-01 (commit: d65efe7c951371fbad2c426b59bbac8bf2e60662)
-- Linux distribution: Debian 9.1 Stretch
-- Machine: Dell Latitude 7275 with an Intel Skylake Core M7-6Y75
-- Display connector: DisplayPort over USB Type-C


When plugging an HP Lap Dock as an external display to my Intel Skylake laptop, this monitor isn't properly detected and configured to its native 1920x1080 resolution. In fact, the external display ends up rebooting after just a few seconds; upon a quick reboot, the setup is tried again, triggering another reboot, etc. in a never-ending loop... This is always reproducible.

It's a bit tricky but it is possible to set it up manually to the minimum exposed 640x480 resolution at least, by executing an xrandr command at the right time, just before the displays reboots.

$ xrandr --output DP-1 --mode 640x480
DP-1 connected 640x480+1280+0 (normal left inverted right x axis y axis) 160mm x 90mm
   1920x1080     60.00 +  59.94
   720x576       50.00
   720x480       60.00    59.94
   640x480       60.00*   59.94

None of the 3 other resolutions exposed by xrandr are working at all when tried manually, but using 640x480 is stable, allowing to test other configurations.

I'm trying to use this display connected to a Dell Latitude 7275 with an Intel Core M7-6Y75 /  Intel HD Graphics 515 (GT2). I've been able to check that this HP Lap Dock can run properly at its native resolution when plugged to other devices such as phones (LG G5, Microsoft Lumia 950) to rule out issues with the hardware itself or the connectivity (as I'm using the same USB Type-C to USB Type-C cable in all cases).

Thanks to randr, I was able to get the EDID info, attached for reference and to create the corresponding edid.bin file to run parse-edid on it. However, trying to create corresponding Modelines with xrandr for the 1920x1080 resolution manually didn't help either.

I'm attaching my dmesg output and Xorg.0.log using a kernel built based on the very recent drm-intel-next-2017-12-01 tag and with drm.debug=0x06. Let me know if other inputs would be useful to investigate this issue. Thanks.


P.S. I don't know if that makes a difference but I should mention that this HP Lap Dock display is somehow unusual, as it only has one DisplayPort over USB Type-C input. Since there are very few adapters/docks with DisplayPort over USB Type-C video output, this limits the testing mainly to devices with such USB-C video ports built-in.
Comment 1 Jérôme de Bretagne 2017-12-03 22:20:47 UTC
Created attachment 135907 [details]
Output of xrandr --verbose
Comment 2 Jérôme de Bretagne 2017-12-03 22:22:20 UTC
Created attachment 135908 [details]
edid.bin for the HP Lap Dock external display
Comment 3 Jérôme de Bretagne 2017-12-03 22:24:27 UTC
Created attachment 135909 [details]
Xorg.0.log when starting a session with the external display already plugged, with drm.debug=0x06
Comment 4 Jérôme de Bretagne 2017-12-03 22:25:43 UTC
Created attachment 135910 [details]
Xorg.0.log when starting the session without the external display, then plugged in, with drm.debug=0x06
Comment 5 Jérôme de Bretagne 2017-12-03 22:27:03 UTC
Created attachment 135911 [details]
dmesg with drm.debug=0x06, with the external display plugged in
Comment 6 Jérôme de Bretagne 2017-12-03 22:29:44 UTC
Created attachment 135912 [details]
syslog when setting the display to 640x480 with xrandr manually, drm.debug=0x06
Comment 7 Jérôme de Bretagne 2017-12-03 22:31:16 UTC
Created attachment 135914 [details]
syslog output when plugging the display during on open X session, with the display ending up rebooting, drm.debug=0x06
Comment 8 Jérôme de Bretagne 2017-12-03 22:31:44 UTC
Created attachment 135915 [details]
2nd syslog output when plugging the display during on open X session, with the display ending up rebooting, drm.debug=0x06
Comment 9 Jérôme de Bretagne 2017-12-19 21:24:47 UTC
FYI I've just tested a more recent kernel, built at the drm-intel-next-2017-12-14 tag (commit: ee5b5bf351ec8cd8f11c631cb76b30f602e866ee), I get the exact same behavior.

I'll be happy to provide any other inputs that could be helpful to investigate this issue.

Thanks, Jérôme
Comment 10 Jérôme de Bretagne 2018-03-04 14:23:42 UTC
FYI I've just tested a more recent kernel, built at the drm-intel-next-2018-02-21 tag (commit: fed8165851e262575585b22055ff5dba7d91b0e5), I get the exact same behavior.

Anyone from Intel willing to investigate this issue? Just let me know which inputs would be useful and I'll do my best to provide them in a timely manner.

Thanks, Jérôme
Comment 11 Elizabeth 2018-03-05 17:28:28 UTC
Hello Jerome, could you attach a dmesg or kern.log that contains the whole boot information? From the power on, the setting up and if possible the event of reboot.
Comment 12 Jérôme de Bretagne 2018-03-05 19:36:50 UTC
Created attachment 137795 [details]
dmesg with more recent drm-intel-next-2018-02-21 kernel
Comment 13 Jérôme de Bretagne 2018-03-05 19:37:36 UTC
Created attachment 137796 [details]
kern.log with more recent drm-intel-next-2018-02-21 kernel
Comment 14 Jérôme de Bretagne 2018-03-05 19:51:41 UTC
Hello Elizabeth,

Here you go, I've just attached both dmesg and kern.log with a drm-intel-next-2018-02-21 kernel from power on, with the external screen detached at first, then plugged in.

In that scenario, I've let the external HP screen reboot once, then I've unplugged it right after the second reboot and finally I've taken the logs. I don't see anything particularly useful in these normal logs about this display issue, most entries are hid / USB related as this external screen also exposes a touchpad and a keyboard over USB Type-C.

Let me know if you would prefer other logs with more debug info.

Thanks,
Jérôme
Comment 15 Elizabeth 2018-03-05 23:51:45 UTC
Direct firmware load for i915/skl_dmc_ver1_27.bin failed with error -2
Mar  5 20:25:46 latitude-7275 kernel: [    3.688974] i915 0000:00:02.0: Failed to load DMC firmware i915/skl_dmc_ver1_27.bin. Disabling runtime power management.
Mar  5 20:25:46 latitude-7275 kernel: [    3.688975] i915 0000:00:02.0: DMC firmware homepage: https://01.org/linuxgraphics/downloads/firmware

Could you try https://bugs.freedesktop.org/show_bug.cgi?id=101991#c18?

Also I forget to ask the logs with drm.debug=0x1e parameter, sorry.

[    3.141439] PM: Starting manual resume from disk
[    3.141494] PM: Image not found (code -22)

Guess this is where it reboots.
Comment 16 Jérôme de Bretagne 2018-03-06 12:42:03 UTC
Created attachment 137823 [details]
kern.log with more recent drm-intel-next-2018-02-21 kernel and drm_debug=0x1e set
Comment 17 Jérôme de Bretagne 2018-03-06 13:02:10 UTC
Created attachment 137824 [details]
kern.log with more recent drm-intel-next-2018-02-21 kernel and drm_debug=0x1e set

version with firmware loading error fixed, to avoid confusion, as it is not related with the actual issue
Comment 18 Jérôme de Bretagne 2018-03-06 13:11:29 UTC
Hello Elizabeth,

The firmware loading error message is unrelated to the actual issue, I've fixed it by downloading the missing 1.27 firmware binary on my system, but the HP Lap Dock display is still not properly detected and reboots after a few seconds when plugged.

I've just attached a newer kern.log file with drm.debug=0x1e parameter set this time, as you've requested and with firmware 1.27 properly loaded. The output is much more verbose, let me know if you detect anything useful.

Thanks, Jérôme
Comment 19 Jérôme de Bretagne 2018-03-06 13:17:45 UTC
And I forgot to mention it, as there may be a confusion: this is the external screen that is rebooting, not my laptop, so the "PM:" entry in the logs would be unrelated. The external display rebooting will appear I guess as if it has been unplugged then plugged back again.
Comment 20 Elizabeth 2018-03-07 18:05:54 UTC
(In reply to Jérôme de Bretagne from comment #19)
> And I forgot to mention it, as there may be a confusion: this is the
> external screen that is rebooting, not my laptop, so the "PM:" entry in the
> logs would be unrelated. The external display rebooting will appear I guess
> as if it has been unplugged then plugged back again.
Thanks for the clarification.

Guess could be this then:

[   77.263201] usb 3-1: USB disconnect, device number 2
[   77.263205] usb 3-1.3: USB disconnect, device number 3
[   77.263289] xhci_hcd 0000:37:00.0: WARN Event TRB for slot 3 ep 2 with no TDs queued?
[   77.263314] xhci_hcd 0000:37:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
[   77.346649] [drm:drm_mode_object_put [drm]] OBJ ID: 71 (3)
[   77.346679] [drm:drm_ioctl [drm]] pid=688, dev=0xe200, auth=1, DRM_IOCTL_MODE_GETCONNECTOR
[   77.378797] [drm:drm_mode_object_put [drm]] OBJ ID: 66 (4)
[   77.378832] [drm:drm_ioctl [drm]] pid=926, dev=0xe200, auth=1, DRM_IOCTL_MODE_GETCONNECTOR
[   77.378856] [drm:drm_mode_object_put [drm]] OBJ ID: 66 (4)
[   77.378883] [drm:drm_ioctl [drm]] pid=926, dev=0xe200, auth=1, DRM_IOCTL_MODE_GETCONNECTOR
[   77.378983] [drm:drm_sysfs_hotplug_event [drm]] generating hotplug event
[   77.408759] usb 3-1.4: USB disconnect, device number 4
[   77.455915] usb 4-1: USB disconnect, device number 2
[   77.526588] xhci_hcd 0000:37:00.0: xHCI host controller not responding, assume dead
[   77.526593] xhci_hcd 0000:37:00.0: HC died; cleaning up
[   77.531755] [drm:drm_mode_object_put [drm]] OBJ ID: 71 (4)
[   77.531786] [drm:drm_ioctl [drm]] pid=926, dev=0xe200, auth=1, DRM_IOCTL_MODE_GETCONNECTOR
[   77.531799] [drm:drm_mode_object_put [drm]] OBJ ID: 71 (3)
[   77.531817] [drm:drm_ioctl [drm]] pid=688, dev=0xe200, auth=1, DRM_IOCTL_MODE_GETCONNECTOR
[   77.550150] xhci_hcd 0000:37:00.0: remove, state 4
[   77.550158] usb usb4: USB disconnect, device number 1
[   77.550403] xhci_hcd 0000:37:00.0: USB bus 4 deregistered
[   77.550411] xhci_hcd 0000:37:00.0: remove, state 1
[   77.550416] usb usb3: USB disconnect, device number 1
[   77.550757] xhci_hcd 0000:37:00.0: Host halt failed, -19
[   77.550760] xhci_hcd 0000:37:00.0: Host not accessible, reset failed.
[   77.550868] xhci_hcd 0000:37:00.0: USB bus 3 deregistered
[   77.551303] pcieport 0000:02:00.0: Refused to change power state, currently in D3
[   77.553036] pci_bus 0000:03: busn_res: [bus 03] is released
[   77.553127] pci_bus 0000:04: busn_res: [bus 04-36] is released
[   77.555785] pci_bus 0000:37: busn_res: [bus 37] is released
[   77.556060] pci_bus 0000:38: busn_res: [bus 38-6b] is released
[   77.556133] pci_bus 0000:02: busn_res: [bus 02-6b] is released

And at the end a bunch of missed vblanks:

[drm:drm_calc_vbltimestamp_from_scanoutpos [drm]] crtc 1 : v p(0,280)@ 104.139859 -> 104.137759 [e 0 us, 0 rep]
[  104.139613] [drm:drm_vblank_restore [drm]] missed 10 vblanks in 166675243 ns, frame duration=16667604 ns, hw_diff=10
[  104.139629] [drm:drm_vblank_enable [drm]] enabling vblank on crtc 1, ret: 0

Let's wait for someone to take a look at this with the new logs.

Thanks for your patience.
Comment 21 Jani Saarinen 2018-03-29 07:11:39 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 22 Jérôme de Bretagne 2018-04-01 16:29:28 UTC
Hi Jani, thanks for the update. I've shared my feedback based on recent drm-intel-next tags until now, I'm happy to provide my input based on drm-tip moving forward if that's more useful. I'll update this bug as requested in a few days then. It would be nice to know if someone from Intel has started to investigate a bit further already using the shared logs. Anything useful in there?
Comment 23 Jérôme de Bretagne 2018-04-07 22:25:26 UTC
Testing a kernel built a few days ago from drm-tip gives exactly the same issue as described in the original description.

For reference, I've tested at:

commit c46052cde6a50c5459e00791ffc4d5aa1ec58a9e
Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
Date:   Fri Mar 30 12:13:21 2018 -0700

    drm-tip: 2018y-03m-30d-18h-56m-26s UTC integration manifest
Comment 24 Jani Saarinen 2018-04-25 10:30:16 UTC
Jani, any advice here?
Comment 25 Jani Nikula 2018-04-25 11:48:15 UTC
Please re-test current drm-tip with drm.debug=14 module parameter and attach dmesg from boot. I'm afraid the previous debug logs have excessive logging.
Comment 26 Jérôme de Bretagne 2018-04-25 22:19:16 UTC
Created attachment 139113 [details]
dmesg for drm-tip: 2018y-04m-25d-17h-38m-40s UTC and drm.debug=14

Here you go Jani, I've just attached a new dmesg output with drm.debug=14 as requested, tested on the current drm-tip from power on, with the external screen detached at first, then plugged in.

In that scenario, I've let the external HP screen reboot once, then twice before unplugging it to finally stop taking these logs.
Comment 27 Jérôme de Bretagne 2018-04-25 22:26:29 UTC
The current drm-tip kernel I've just tested was built for reference at:

commit 241bdd3f88af652071b871fea170b3b7e89a521c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Apr 25 19:39:34 2018 +0200

    drm-tip: 2018y-04m-25d-17h-38m-40s UTC integration manifest
Comment 28 Jérôme de Bretagne 2018-04-25 22:55:28 UTC
Created attachment 139115 [details]
syslog for drm-tip: 2018y-04m-25d-17h-38m-40s UTC and drm.debug=14

The previously attached dmesg output didn't show the logs from boot due to excessive logging, so here is a syslog output instead.
Comment 29 Jérôme de Bretagne 2018-04-25 23:01:49 UTC
Created attachment 139116 [details]
kern.log for drm-tip: 2018y-04m-25d-17h-38m-40s UTC and drm.debug=14

And finally a focus on the "kernel:" lines, here again from boot up, then starting Gnome, then plugging the external HP screen, letting it reboot twice due to being not detected / enabled properly.
Comment 30 Jérôme de Bretagne 2018-04-25 23:14:52 UTC
To guide a bit in the kern.log output, the HP Lap Dock external screen is first plugged  in around 22s, as visible with the new usb lines starting with:
   kernel: [   22.308583] usb 4-2: new SuperSpeed USB device number 2 using xhci_hcd

and it is explicitly mentioned a bit later at the line:
   kernel: [   24.463986] [drm:drm_add_edid_modes [drm]] ELD monitor HP Lap Dock
Comment 31 Jérôme de Bretagne 2018-07-03 19:53:31 UTC
I've just discovered the on-going work by Heikki Krogerus to officially support USB Type-C Alternate Modes here: https://lkml.org/lkml/2018/6/27/400 and the need for changes also to the drm subsystem here: https://lkml.org/lkml/2018/6/8/225

I've also found an older comment from Hans de Goede here: https://www.reddit.com/r/GPDPocket/comments/7niut2/fix_for_broken_touch_after_resume_all_linux/dso0nku/ giving a broad overview of the various steps still required to support USB Type-C video-out on another product.

Now I'm confused about which parts of DisplayPort over USB Type-C are expected to work out-of-the-box on Linux today. I thought, maybe too quickly, that getting the 640x480 resolution working was a good sign that most pieces for DisplayPort Alternate Mode were already in place, but that may not be that simple...

I'll follow the continued progress on that topic and I'll be happy to test and provide feedback on the results I get with the HP Lad Dock, once it makes sense to give it another try.

Thanks, Jérôme
Comment 32 Rodrigo Vivi 2018-07-05 18:41:24 UTC
Hi Jérôme,

This shouldn't be related to this alternate_mode discussion. Your mode should be supported. I'm using myself SKL with DP on USB-typeC for about 1 year already. 4k and full-hd resolutions.

Also, the modeset failing should never cause any reboot. This is strange. Could you please describe a bit better this reboot that is happening?

Also probably better if you could point the time on the log that reboot is happening.

Also, could you please upload updated version of xorg logs (xorg.0.log and xrandr --verbose) since the new drm-tip logs and xrandr verbose doesn't match on the DP port that you are using.

Also even better if you use latest drm-tip and updated xserver as well.

Thanks,
Rodrigo.
Comment 33 Jérôme de Bretagne 2018-07-05 20:18:11 UTC
Hi Rodrigo,

Thanks for your input. Could you expand a bit why you believe "This shouldn't be related to this alternate mode discussion"? Could you also share which display with USB Type-C input is working for you, for reference?

For this HP external screen model rebooting, I have two assumptions: 1/ either a correct modeset is maybe taking too long to happen (compared to an internal timer), or 2/ an unexpected modeset is triggering a bug in the display itself.

This portable display can work as both a wireless display or a wired display (with DisplayPort over USB Type-C) and is showing a screen on startup to expose the 2 modes, waiting for one or the other. After plugging it via USB Type-C, it is trying to get configured in wired mode, but (assumption 1/) if it takes too long, maybe it decides to expose the initial screen again to offer the 2 options (wired or wireless), so it reboots. But since it is still plugged in via USB, it tries to get configured in wired mode again. And again, and again.

I'll try to point the time in the logs when the reboots happen for the next time I'll share updated logs taken on a more current drm-tip. I'll see if I can update xserver on that occasion too, but I've never done that yet.

Thanks, Jérôme
Comment 34 Lakshmi 2018-08-26 04:57:45 UTC
> I'll try to point the time in the logs when the reboots happen for the next
> time I'll share updated logs taken on a more current drm-tip. I'll see if I
> can update xserver on that occasion too, but I've never done that yet.
> 
Do you now have the logs with exact time stamp?
Comment 35 Jérôme de Bretagne 2018-08-26 10:25:47 UTC
Created attachment 141281 [details]
syslog for linux-4.18.0 with drm.debug=14

Here you go, Lakshmi, I'm attaching a new syslog output with Linux 4.18.0 and  drm.debug=14
Comment 36 Jérôme de Bretagne 2018-08-26 10:31:54 UTC
Created attachment 141282 [details]
Xorg.0.log for Linux 4.18.0 with drm.debug=14

Updated Xorg.0.log running Linux 4.18.0 when starting the session without the HP Lapdock plugged in at first, then plugged in
Comment 37 Jérôme de Bretagne 2018-08-26 10:42:32 UTC
Created attachment 141283 [details]
xrandr --verbose on Linux 4.18.0 with the HP Lap Dock plugged on DP-1

Updated xrandr --verbose output taken on Linux 4.18.0, with the HP Lap Dock plugged on DP-1 (this is the top USB Type-C port among the 2 of the Latitude 7275 model) forced manually at 640x480, as requested by Rodrigo
Comment 38 Jérôme de Bretagne 2018-08-26 10:46:33 UTC
Created attachment 141284 [details]
kern.log for Linux 4.18.0 with drm.debug=14

Updated kern.log with Linux 4.18.0 and drm.debug=14
Comment 39 Jérôme de Bretagne 2018-08-26 11:50:42 UTC
As requested, Rodrigo and Lakshmi, here is the scenario I've run through for the updated logs I've just shared. I've let the laptop boot without the HP Lap Dock plugged at first, I've logged into my Gnome session and only then I've plugged this external display to DP-1.

In terms of time stamps, I've taken a video with a timer started close to the initial boot (right after grub) to better measure. Here are the main events:

1/ the HP Lap Dock is plugged at around 26-27s

I think visible in the logs at:
[   26.577340] [drm:gen8_de_irq_handler [i915]] hotplug event received, stat 0x00200000, dig 0x10101012, pins 0x00000020
[   26.577402] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[   26.577457] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0
[   26.577586] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[   26.577661] [drm:i915_hotplug_work_func [i915]] running encoder hotplug functions
[   26.577721] [drm:i915_hotplug_work_func [i915]] Connector DP-1 (pin 5) received hotplug event.
[   26.577777] [drm:intel_dp_detect [i915]] [CONNECTOR:78:DP-1]

and for the USB side of things right after at:
[   27.229828] usb 3-1.4: New USB device found, idVendor=03f0, idProduct=0c56, bcdDevice= 0.00
[   27.229837] usb 3-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   27.229842] usb 3-1.4: Product: HP Elite x3 Lap Dock


2/ the HP Lap Doc reboots at around 44-45s, so after 18s being plugged in, so displaying the HP boot logo.

In the logs, I believe it is around:
[   45.472235] [drm:i915_hotplug_work_func [i915]] Connector DP-1 (pin 5) received hotplug event.
[   45.472263] [drm:intel_dp_detect [i915]] [CONNECTOR:78:DP-1]
[   45.472299] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:78:DP-1] status updated from connected to disconnected

Surprisingly, the USB events are  visible even earlier:
[   40.013014] usb 3-1.4: New USB device found, idVendor=03f0, idProduct=0c56, bcdDevice= 0.00
[   40.013017] usb 3-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   40.013018] usb 3-1.4: Product: HP Elite x3 Lap Dock


3/ It takes a few seconds for the display to restart, showing the screen offering either wireless or wired connectivity at around 54s, and the screen goes black when trying to connect over USB Type-C at 56s.

However, in the logs, I can see events much earlier right after the reboots, such as:

[   47.050905] [drm:i915_hotplug_work_func [i915]] Connector DP-1 (pin 5) received hotplug event.
[   47.050930] [drm:intel_dp_detect [i915]] [CONNECTOR:78:DP-1]
[   47.050952] [drm:intel_power_well_enable [i915]] enabling power well 2
[   47.053624] [drm:intel_dp_read_dpcd [i915]] DPCD: 12 14 81 01 21 11 01 80 00 00 04 00 00 00 02
[   47.057861] [drm:intel_dp_print_rates [i915]] source rates: 162000, 216000, 270000, 324000, 432000, 540000
[   47.057883] [drm:intel_dp_print_rates [i915]] sink rates: 162000, 270000, 540000
[   47.057902] [drm:intel_dp_print_rates [i915]] common rates: 162000, 270000, 540000


4/ Finally, I get a second reboot at 1min12s / 1min13s with the HP boot logo being displayed again, at which time I unplug the USB Type-C cable from the laptop to end the loop.


I hope this gives you enough input to better analyze what could be going wrong from these logs.

Thanks, Jérôme
Comment 40 Rodrigo Vivi 2018-08-27 23:05:08 UTC
One thing that is strange is that it seems that there is a hotplug in the middle of modeset that is working correctly. Link train happens etc, but the is a point with another hotplug.

Anyway,

Could you please use intel gpu tool to check
$ sudo intel_reg read 0xc2014

also it is good:
$ sudo intel_reg dump

and also please

$ sudo cat /sys/kernel/debug/dri/0/i915_display_info


-----

There is another thing really strange on the log.

At first sight I thought a PSR related message along to DP-1 was just a pollution on our log, than when I was going to only print PSR msg if eDP I noticed that our flow is already protected so this PSR related message shouldn't be here:

Aug 26 11:30:38 latitude-7275 kernel: [   27.817517] [drm:intel_atomic_check [i915]] [CONNECTOR:78:DP-1] checking for sink bpp constrains
Aug 26 11:30:38 latitude-7275 kernel: [   27.817633] [drm:intel_atomic_check [i915]] clamping display bpp (was 36) to EDID reported max of 24
Aug 26 11:30:38 latitude-7275 kernel: [   27.817749] [drm:intel_dp_compute_config [i915]] DP link computation with max lane count 1 max rate 540000 max bpp 24 pixel clock 148500KHz
Aug 26 11:30:38 latitude-7275 kernel: [   27.817851] [drm:intel_dp_compute_config [i915]] DP lane count 1 clock 540000 bpp 24
Aug 26 11:30:38 latitude-7275 kernel: [   27.817958] [drm:intel_dp_compute_config [i915]] DP link rate required 445500 available 540000
Aug 26 11:30:38 latitude-7275 kernel: [   27.818056] [drm:intel_dp_compute_config [i915]] PSR disable by flag
Comment 41 Jérôme de Bretagne 2018-08-27 23:44:02 UTC
Thanks Rodrigo for the investigation, I'll try to provide the next inputs soon.

Just to be sure, do I need to run the requested commands in a specific situation: Lap Dock plugged and rebooting / Lap Dock forced stable at 640x480 / unplugged / doesn't matter?
Comment 42 Rodrigo Vivi 2018-08-28 14:42:30 UTC
probably doesn't matter, but maybe good to run the commands on both scenarios, after booting and after forcing to low res...
Comment 43 Jérôme de Bretagne 2018-08-28 18:41:44 UTC
For the first command, I get exactly the same result in all scenarios: without the external display plugged, with it plugged (but unstable) or with it forced in low res. Here it is:

   $ sudo intel_reg read 0xc2014
   (0x000c2014): 0x00000006 (display enabled, crt no, lane reversal no, port b yes, port c yes, port d no)

I'm going to add the results of the 2 other commands as file attachments. When the external display was plugged but unstable, I took 4 different measures as doing a quick diff showed quite a few differences depending on the timing. 


PS1. v1 for one file doesn't match the timing of v1 for the other file by the way, to avoid a possible confusion

PS2. The measure is not simple to do as the built-in panel also blinks while the system is trying to set the configuration for all screens altogether. I don't know if that's expected, I would (naively) expect the main screen to remain configured in its current resolution while only the 2nd is being configured.
Comment 44 Jérôme de Bretagne 2018-08-28 18:44:33 UTC
Created attachment 141313 [details]
intel_reg dump - Lap Dock forced in low resolution
Comment 45 Jérôme de Bretagne 2018-08-28 18:45:11 UTC
Created attachment 141314 [details]
intel_reg dump - Lap Dock plugged but unstable - take 1
Comment 46 Jérôme de Bretagne 2018-08-28 18:45:29 UTC
Created attachment 141315 [details]
intel_reg dump - Lap Dock plugged but unstable - take 2
Comment 47 Jérôme de Bretagne 2018-08-28 18:45:45 UTC
Created attachment 141316 [details]
intel_reg dump - Lap Dock plugged but unstable - take 3
Comment 48 Jérôme de Bretagne 2018-08-28 18:46:02 UTC
Created attachment 141317 [details]
intel_reg dump - Lap Dock plugged but unstable - take 4
Comment 49 Jérôme de Bretagne 2018-08-28 18:46:58 UTC
Created attachment 141318 [details]
cat /sys/kernel/debug/dri/0/i915_display_info  - Lap Dock forced in low resolution
Comment 50 Jérôme de Bretagne 2018-08-28 18:47:50 UTC
Created attachment 141319 [details]
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock plugged but unstable - take 1
Comment 51 Jérôme de Bretagne 2018-08-28 18:48:10 UTC
Created attachment 141320 [details]
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock plugged but unstable - take 2
Comment 52 Jérôme de Bretagne 2018-08-28 18:48:27 UTC
Created attachment 141321 [details]
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock plugged but unstable - take 3
Comment 53 Jérôme de Bretagne 2018-08-28 18:48:42 UTC
Created attachment 141322 [details]
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock plugged but unstable - take 4
Comment 54 Lakshmi 2018-10-17 15:26:43 UTC
Rodrigo, any advice to proceed further?
Comment 55 Rodrigo Vivi 2019-03-05 00:59:20 UTC
Created attachment 143525 [details] [review]
Experiment 1. Crop link rate to 162000

The whole dock seems to be rebooting right after a link training with a high rate. I'd like to be able to experiment some lower rates without forcing low res modes to see what happens.
Comment 56 Rodrigo Vivi 2019-03-05 00:59:58 UTC
Created attachment 143526 [details] [review]
Experiment 2. Crop link rate to 270000
Comment 57 Rodrigo Vivi 2019-03-05 01:00:43 UTC
Well, since it was a long time, probably good to check pure drm-tip before the patches.
I'm sorry for the delay here.
Rodrigo.
Comment 58 Jérôme de Bretagne 2019-03-21 23:22:11 UTC
Hi Rodrigo, I did compile a more recent drm-tip a couple weeks ago at:

   commit 29a41cf5dd10ee68873c16b67d6212b3bd470906
   Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
   Date:   Wed Mar 6 22:18:58 2019 +0200
   
       drm-tip: 2019y-03m-06d-20h-18m-08s UTC integration manifest

With some delay, I'm happy to report that the Lapdock has properly been detected and switched to its native 1920x1080 @ 60Hz resolution for the very first time ever, in the exact same hardware setup as originally reported in this bug!

To avoid confusion, this is pure drm-tip above, no patches applied.

I have no idea what change(s) since kernel 4.18 could explain this new outcome. If that's of interest to anyone, I could try to bissect back to find when it started working, but it could take me quite a while.

The monitor detection seems stable and reproducible during my tests today, doing many unplug/replug checks ... as long as I keep the default relative positioning of my 2 monitors. However, if I try to change the position of this Lapdock screen next to my main one using the Gnome display settings (from the right side to the left side for instance), my 2 screens blinks several times for a few seconds and Gnome finally reverts to the previous known working config. This is a different issue though.
Comment 59 Jérôme de Bretagne 2019-03-24 14:30:52 UTC
For info, it's also working fine when testing a slightly more recent drm-tip :

   commit 3b6d09692ea282a3487bdf972a068d312a67ca00
   Author: Rodrigo Vivi <rodrigo.vivi@intel.com>
   Date:   Thu Mar 21 13:01:16 2019 -0700
   
       drm-tip: 2019y-03m-21d-20h-00m-41s UTC integration manifest
Comment 60 Rodrigo Vivi 2019-06-17 16:50:10 UTC
Hi Jerome,

Thanks for checking that out.

Since we had a lot of history here on this bug entry and the new bad behavior
is so different from the original one I believe the best to do is to close
this bug as fixed and file a new one with logs and info on the new behavior.

Could you please do that?

Also, for the new one, I believe it is also good to test modesets using xrandr besides gnome tool so we can try to narrow down a bit the failure and not depend on specific user space component.

Thanks in advance,
Rodrigo.
Comment 61 Jérôme de Bretagne 2019-06-17 19:40:44 UTC
Hi Rodrigo,

Thanks for your feedback. As suggested, I'm closing this bug as fixed, tested to be working at least since Linux v5.1 on my setup.

I'll try to find some time in the coming weeks to file another one for the other issue, taking logs using xrandr as recommaeded to narrow down the potential root cause.

Thanks again,
Jérôme


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.