On Wed, Sep 07, 2022 at 05:29:14PM +0200, Paul Kelly wrote:
> On 9/7/22 13:05, Jonathan Gray wrote:
> > If you add "option DRMDEBUG" to your kernel config
> > there may be some hints in the (large amount of) dmesg output
> >
> > Also build with this to add some more DP messages.
> > Used in sys/dev/pci/drm/drm_dp_mst_topology.c
> >
> > Index: sys/dev/pci/drm/drm_print.c
> > ===================================================================
> > RCS file: /cvs/src/sys/dev/pci/drm/drm_print.c,v
> > retrieving revision 1.4
> > diff -u -p -r1.4 drm_print.c
> > --- sys/dev/pci/drm/drm_print.c 12 Jun 2020 10:06:40 -0000 1.4
> > +++ sys/dev/pci/drm/drm_print.c 7 Sep 2022 10:38:00 -0000
> > @@ -43,7 +43,7 @@
> > * Bitmask of DRM_UT_x. See include/drm/drm_print.h for details.
> > */
> > #ifdef DRMDEBUG
> > -unsigned int __drm_debug = DRM_UT_DRIVER | DRM_UT_KMS;
> > +unsigned int __drm_debug = DRM_UT_DRIVER | DRM_UT_KMS | DRM_UT_DP;
> > #else
> > unsigned int __drm_debug;
> > #endif
>
> Thanks; I think I have identified the problem.
>
> I rebuilt against -current with the suggested modifications. This is tested
> on the HP ProDesk w/ 1x DP + 1x VGA output; only the DP output is in use,
> and it's connected to a monitor with MST enabled. I've included the dmesg
> output at the bottom.
>
> I've noticed that DP MST seems to be supported by both port and sink (host
> system and monitor respectively, I am guessing). However, it's being
> administratively disabled via a check on the following variable:
> i915->params.enable_dp_mst (see "modparam:no" in the log message below).
>
> > [drm] [ENCODER:73:DDI B/PHY B] MST support: port: yes, sink: yes, modparam:
> > no
>
> Digging a bit further...the params struct is defined in i915_params.h, and
> its members are initialised to specific values that are subsequently used as
> the initial configuration for i915 devices in Linux (see call to
> i915_params_copy() in i915_drv.c). This is however not performed under
> OpenBSD, because it's buried in an #ifdef __linux__ section. So it looks
> like we are simply missing some intended default configuration.
>
> I've included a bodge below to ignore enable_dp_mst entirely, and I have
> confirmed that this restores my ability to run with DisplayPort MST. I am
> assuming that it's safe to set enable_dp_mst true by default in OpenBSD, but
> that seems unlikely to help other users who are not relying on MST for
> multi-screen support.
>
> My initial approach to fix this properly would be to introduce
> OpenBSD-conditional config into i915_params.h and then update
> i915_driver_probe() so that it calls i915_params_copy() early. Then it would
> be possible to incrementally identify which defaults are appropriate. If
> that's acceptable then I'm happy to prepare a diff for testing.
>
> Thanks again for the tips to investigate this - it's a great relief to have
> understood the issue and it will be nice to get use of my second screen
> again.
>
> Paul
well spotted
comparing the before and after here I see
struct drm_printer p = drm_info_printer(dev_priv->drm.dev);
i915_params_dump(&dev_priv->params, &p);
i915_params_copy(&dev_priv->params, &i915_modparams);
i915_params_dump(&dev_priv->params, &p);
@@ -1,36 +1,36 @@
[drm] i915.vbt_firmware=(null)
-[drm] i915.modeset=0
+[drm] i915.modeset=-1
[drm] i915.lvds_channel_mode=0
-[drm] i915.panel_use_ssc=0
-[drm] i915.vbt_sdvo_panel_type=0
-[drm] i915.enable_dc=0
-[drm] i915.enable_fbc=0
-[drm] i915.enable_psr=0
+[drm] i915.panel_use_ssc=-1
+[drm] i915.vbt_sdvo_panel_type=-1
+[drm] i915.enable_dc=-1
+[drm] i915.enable_fbc=-1
+[drm] i915.enable_psr=-1
[drm] i915.psr_safest_params=no
[drm] i915.enable_psr2_sel_fetch=no
-[drm] i915.disable_power_well=0
-[drm] i915.enable_ips=0
+[drm] i915.disable_power_well=-1
+[drm] i915.enable_ips=1
[drm] i915.invert_brightness=0
-[drm] i915.enable_guc=0
-[drm] i915.guc_log_level=0
+[drm] i915.enable_guc=-1
+[drm] i915.guc_log_level=-1
[drm] i915.guc_firmware_path=(null)
[drm] i915.huc_firmware_path=(null)
[drm] i915.dmc_firmware_path=(null)
[drm] i915.mmio_debug=0
[drm] i915.edp_vswing=0
-[drm] i915.reset=0
+[drm] i915.reset=3
[drm] i915.inject_probe_failure=0
-[drm] i915.fastboot=0
-[drm] i915.enable_dpcd_backlight=0
-[drm] i915.force_probe=(null)
+[drm] i915.fastboot=-1
+[drm] i915.enable_dpcd_backlight=-1
+[drm] i915.force_probe=
[drm] i915.fake_lmem_start=0
-[drm] i915.request_timeout_ms=0
-[drm] i915.enable_hangcheck=no
+[drm] i915.request_timeout_ms=20000
+[drm] i915.enable_hangcheck=yes
[drm] i915.load_detect_test=no
[drm] i915.force_reset_modeset_test=no
-[drm] i915.error_capture=no
+[drm] i915.error_capture=yes
[drm] i915.disable_display=no
-[drm] i915.verbose_state_checks=no
+[drm] i915.verbose_state_checks=yes
[drm] i915.nuclear_pageflip=no
-[drm] i915.enable_dp_mst=no
+[drm] i915.enable_dp_mst=yes
[drm] i915.enable_gvt=no
with the request_timeout_ms change, on broadwell I see
Fence expiration time out i915-:Xorg[37259]:10!
drm:pid20607:__intel_engine_reset_bh *NOTICE* [drm] Resetting rcs0 for request
cancellation by drmwq
drm:pid20607:mark_guilty *NOTICE* [drm] Xorg[37259] context reset due to GPU
hang
So, leaving that as 0 and continuing to disable GuC
Index: sys/dev/pci/drm/i915/i915_drv.c
===================================================================
RCS file: /cvs/src/sys/dev/pci/drm/i915/i915_drv.c,v
retrieving revision 1.143
diff -u -p -r1.143 i915_drv.c
--- sys/dev/pci/drm/i915/i915_drv.c 30 Jul 2022 14:15:20 -0000 1.143
+++ sys/dev/pci/drm/i915/i915_drv.c 8 Sep 2022 00:33:22 -0000
@@ -2410,6 +2410,11 @@ inteldrm_attach(struct device *parent, s
dev_priv->id = id;
info = (struct intel_device_info *)id->driver_data;
+ /* Device parameters start as a copy of module parameters. */
+ i915_params_copy(&dev_priv->params, &i915_modparams);
+ dev_priv->params.enable_guc = 0;
+ dev_priv->params.request_timeout_ms = 0;
+
/* Setup the write-once "constant" device info */
device_info = mkwrite_device_info(dev_priv);
memcpy(device_info, info, sizeof(*device_info));
