On 2024/10/30 10:23, Jonathan Gray wrote: > On Tue, Oct 29, 2024 at 10:30:45PM +0000, Stuart Henderson wrote: > > On 2024/10/18 13:28, Stuart Henderson wrote: > > > On 2024/10/14 14:30, Stuart Henderson wrote: > > > > On 2024/10/08 11:08, Mark Kettenis wrote: > > > > > > > $ ls -lh /var/log/Xorg.0.log* > > > > > > > -rw-r--r-- 1 root wheel 45.6K Oct 7 13:37 /var/log/Xorg.0.log > > > > > > > -rw-r--r-- 1 root wheel 433M Oct 3 11:48 > > > > > > > /var/log/Xorg.0.log.old > > > > > > > > > > > > > > hmm, there are loads of modeline dumps: > > > > > > > > > > Probably means there is an issue with hotplug detection. Could be a > > > > > dodgy cable, but if it happens on more machines that is unlikely. > > > > > > > > There are two types of machine, running the exact same config / > > > > software, with the same monitor type. Mostly the newer ones with > > > > > > > > + (II) modeset(0): glamor X acceleration enabled on Mesa Intel(R) > > > > Graphics (ADL-N) > > > > + (II) modeset(0): [DRI2] DRI driver: iris > > > > > > > > which are seeing the problem, but there are still a few older > > > > ones with > > > > > > > > - (II) modeset(0): glamor X acceleration enabled on Mesa Intel(R) HD > > > > Graphics 4400 (HSW GT2) > > > > - (II) modeset(0): [DRI2] DRI driver: crocus > > > > > > > > which aren't running into it. > > > > > > > > I'll get a test machine and have a look at DRMDEBUG for clues there, > > > > any suggestions for anything else I can look at? > > > > > > I've not got a test machine running yet, but from observations (I > > > haven't gone through all the logs to verify, those "seconds after start" > > > logs are a pain to correlate with time of day!) it seems to only happen > > > when the monitor is in a dpms power-saving mode. Not sure if that > > > rings any bells.. > > > > So, these definitely happen frequently with the monitor in power-saving, > > and don't seem to happen otherwise. DRMDEBUG shows they are hotplug > > events: > > > > Oct 29 20:51:33 ... /bsd: [drm] hotplug event received, stat 0x00010000, > > dig 0x0000008a, pins 0x00000010, long 0x00000010 > > does this backported diff help? > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e4b90fbe75536c978218bb3eb1d04f8988e13cd
Thanks for finding this - unfortunately not. Testing the various states with xset dpms force [xx], the hotplug events happen with any of standby/suspend/off states. > commit 2e4b90fbe75536c978218bb3eb1d04f8988e13cd > Author: Imre Deak <imre.d...@intel.com> > Date: Thu Jan 4 10:30:07 2024 +0200 > > drm/i915: Filter out glitches on HPD lines during hotplug detection > > Glitches deasserting the connector HPD line can lead to incorrectly > detecting a disconnect event (a glitch asserting the line will only > cause a redundant connect->disconnect transition). The source of such a > glitch can be noise on the line or a 0.5ms-1ms MST IRQ_HPD pulse. TypeC > ports in the DP-alt or TBT-alt mode filter out these glitches inernally, > but for others the driver has to do this. Make it so by polling the HPD > line on these connectors for 4 ms. > > Link: > https://patchwork.freedesktop.org/patch/msgid/20240104083008.2715733-12-imre.d...@intel.com > Reviewed-by: Jouni Högander <jouni.hogan...@intel.com> > Signed-off-by: Imre Deak <imre.d...@intel.com> > > diff --git sys/dev/pci/drm/i915/display/intel_dp.c > sys/dev/pci/drm/i915/display/intel_dp.c > index 5386d3a6bf8..334c22e467d 100644 > --- sys/dev/pci/drm/i915/display/intel_dp.c > +++ sys/dev/pci/drm/i915/display/intel_dp.c > @@ -4702,11 +4702,20 @@ bool intel_digital_port_connected(struct > intel_encoder *encoder) > { > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > struct intel_digital_port *dig_port = enc_to_dig_port(encoder); > + bool is_glitch_free = intel_tc_port_handles_hpd_glitches(dig_port); > bool is_connected = false; > intel_wakeref_t wakeref; > > - with_intel_display_power(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref) > - is_connected = dig_port->connected(encoder); > + with_intel_display_power(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref) { > + unsigned long wait_expires = jiffies + > msecs_to_jiffies_timeout(4); > + > + do { > + is_connected = dig_port->connected(encoder); > + if (is_connected || is_glitch_free) > + break; > + usleep_range(10, 30); > + } while (time_before(jiffies, wait_expires)); > + } > > return is_connected; > } > diff --git sys/dev/pci/drm/i915/display/intel_tc.c > sys/dev/pci/drm/i915/display/intel_tc.c > index 3b8ba487b38..01864c969cb 100644 > --- sys/dev/pci/drm/i915/display/intel_tc.c > +++ sys/dev/pci/drm/i915/display/intel_tc.c > @@ -122,6 +122,15 @@ bool intel_tc_port_in_legacy_mode(struct > intel_digital_port *dig_port) > return intel_tc_port_in_mode(dig_port, TC_PORT_LEGACY); > } > > +bool intel_tc_port_handles_hpd_glitches(struct intel_digital_port *dig_port) > +{ > + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev); > + enum phy phy = intel_port_to_phy(i915, dig_port->base.port); > + struct intel_tc_port *tc = to_tc_port(dig_port); > + > + return intel_phy_is_tc(i915, phy) && !tc->legacy_port; > +} > + > /* > * The display power domains used for TC ports depending on the > * platform and TC mode (legacy, DP-alt, TBT): > diff --git sys/dev/pci/drm/i915/display/intel_tc.h > sys/dev/pci/drm/i915/display/intel_tc.h > index 3b16491925f..6f02741253a 100644 > --- sys/dev/pci/drm/i915/display/intel_tc.h > +++ sys/dev/pci/drm/i915/display/intel_tc.h > @@ -15,6 +15,7 @@ struct intel_encoder; > bool intel_tc_port_in_tbt_alt_mode(struct intel_digital_port *dig_port); > bool intel_tc_port_in_dp_alt_mode(struct intel_digital_port *dig_port); > bool intel_tc_port_in_legacy_mode(struct intel_digital_port *dig_port); > +bool intel_tc_port_handles_hpd_glitches(struct intel_digital_port *dig_port); > > bool intel_tc_port_connected(struct intel_encoder *encoder); > bool intel_tc_port_connected_locked(struct intel_encoder *encoder); >
