Created attachment 135907 [details]
Output of xrandr --verbose

Created attachment 135908 [details]
edid.bin for the HP Lap Dock external display

Created attachment 135909 [details]
Xorg.0.log when starting a session with the external display already plugged, with drm.debug=0x06

Created attachment 135910 [details]
Xorg.0.log when starting the session without the external display, then plugged in, with drm.debug=0x06

Created attachment 135911 [details]
dmesg with drm.debug=0x06, with the external display plugged in

Created attachment 135912 [details]
syslog when setting the display to 640x480 with xrandr manually, drm.debug=0x06

Created attachment 135914 [details]
syslog output when plugging the display during on open X session, with the display ending up rebooting, drm.debug=0x06

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

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

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

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.

Created attachment 137795 [details]
dmesg with more recent drm-intel-next-2018-02-21 kernel

Created attachment 137796 [details]
kern.log with more recent drm-intel-next-2018-02-21 kernel

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

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.

Created attachment 137823 [details]
kern.log with more recent drm-intel-next-2018-02-21 kernel and drm_debug=0x1e set

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

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

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.

(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.

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.

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?

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

Jani, any advice here?

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.

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.

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

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.

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.

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

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

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.

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

> 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?

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

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

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

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

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

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

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?

probably doesn't matter, but maybe good to run the commands on both scenarios, after booting and after forcing to low res...

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.

Created attachment 141313 [details]
intel_reg dump - Lap Dock forced in low resolution

Created attachment 141314 [details]
intel_reg dump - Lap Dock plugged but unstable - take 1

Created attachment 141315 [details]
intel_reg dump - Lap Dock plugged but unstable - take 2

Created attachment 141316 [details]
intel_reg dump - Lap Dock plugged but unstable - take 3

Created attachment 141317 [details]
intel_reg dump - Lap Dock plugged but unstable - take 4

Created attachment 141318 [details]
cat /sys/kernel/debug/dri/0/i915_display_info  - Lap Dock forced in low resolution

Created attachment 141319 [details]
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock plugged but unstable - take 1

Created attachment 141320 [details]
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock plugged but unstable - take 2

Created attachment 141321 [details]
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock plugged but unstable - take 3

Created attachment 141322 [details]
cat /sys/kernel/debug/dri/0/i915_display_info - Lap Dock plugged but unstable - take 4

Rodrigo, any advice to proceed further?

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.

Created attachment 143526 [details] [review]
Experiment 2. Crop link rate to 270000

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.

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.

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

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.

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