* [PATCH v3 0/5] drm/i915: HPD IRQ storm detection fixes
@ 2018-11-03 0:19 Lyude Paul
2018-11-03 0:19 ` [PATCH v3 1/5] drm/i915: Fix possible race in intel_dp_add_mst_connector() Lyude Paul
` (7 more replies)
0 siblings, 8 replies; 12+ messages in thread
From: Lyude Paul @ 2018-11-03 0:19 UTC (permalink / raw)
To: intel-gfx
Cc: David Airlie, Rodrigo Vivi, linux-kernel, dri-devel, Jani Nikula,
Joonas Lahtinen
This series contains a fix for a problem which is very difficult to
reproduce under normal circumstances without specialized testing
hardware, along with a fix that seems to be required for some especially
rebellious GM45 laptops.
Lyude Paul (5):
drm/i915: Fix possible race in intel_dp_add_mst_connector()
drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST
drm/i915: Fix threshold check in intel_hpd_irq_storm_detect()
drm/i915: Clarify flow for disabling IRQs on storms
drm/i915: Add short HPD IRQ storm detection for non-MST systems
drivers/gpu/drm/i915/i915_debugfs.c | 74 ++++++++++++++++++++++++++
drivers/gpu/drm/i915/i915_drv.h | 5 +-
drivers/gpu/drm/i915/i915_irq.c | 7 +++
drivers/gpu/drm/i915/intel_dp_mst.c | 8 +--
drivers/gpu/drm/i915/intel_hotplug.c | 78 +++++++++++++++++-----------
5 files changed, 137 insertions(+), 35 deletions(-)
--
2.19.1
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH v3 1/5] drm/i915: Fix possible race in intel_dp_add_mst_connector() 2018-11-03 0:19 [PATCH v3 0/5] drm/i915: HPD IRQ storm detection fixes Lyude Paul @ 2018-11-03 0:19 ` Lyude Paul 2018-11-03 0:19 ` [PATCH v3 2/5] drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST Lyude Paul ` (6 subsequent siblings) 7 siblings, 0 replies; 12+ messages in thread From: Lyude Paul @ 2018-11-03 0:19 UTC (permalink / raw) To: intel-gfx Cc: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie, dri-devel, linux-kernel This hasn't caused any issues yet that I'm aware of, but as Ville Syrjälä pointed out - we need to make sure that intel_connector->mst_port is set before initializing MST connectors, since in theory we could potentially check intel_connector->mst_port in i915_hpd_poll_init_work() after registering the connector but before having written it's value. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> --- drivers/gpu/drm/i915/intel_dp_mst.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index 8b71d64ebd9d..8cb4093f8bcc 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -441,6 +441,10 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo if (!intel_connector) return NULL; + intel_connector->get_hw_state = intel_dp_mst_get_hw_state; + intel_connector->mst_port = intel_dp; + intel_connector->port = port; + connector = &intel_connector->base; ret = drm_connector_init(dev, connector, &intel_dp_mst_connector_funcs, DRM_MODE_CONNECTOR_DisplayPort); @@ -451,10 +455,6 @@ static struct drm_connector *intel_dp_add_mst_connector(struct drm_dp_mst_topolo drm_connector_helper_add(connector, &intel_dp_mst_connector_helper_funcs); - intel_connector->get_hw_state = intel_dp_mst_get_hw_state; - intel_connector->mst_port = intel_dp; - intel_connector->port = port; - for_each_pipe(dev_priv, pipe) { struct drm_encoder *enc = &intel_dp->mst_encoders[pipe]->base.base; -- 2.19.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v3 2/5] drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST 2018-11-03 0:19 [PATCH v3 0/5] drm/i915: HPD IRQ storm detection fixes Lyude Paul 2018-11-03 0:19 ` [PATCH v3 1/5] drm/i915: Fix possible race in intel_dp_add_mst_connector() Lyude Paul @ 2018-11-03 0:19 ` Lyude Paul 2018-11-03 0:19 ` Lyude Paul ` (5 subsequent siblings) 7 siblings, 0 replies; 12+ messages in thread From: Lyude Paul @ 2018-11-03 0:19 UTC (permalink / raw) To: intel-gfx Cc: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie, dri-devel, linux-kernel Turns out that if you trigger an HPD storm on a system that has an MST topology connected to it, you'll end up causing the kernel to eventually hit a NULL deref: [ 332.339041] BUG: unable to handle kernel NULL pointer dereference at 00000000000000ec [ 332.340906] PGD 0 P4D 0 [ 332.342750] Oops: 0000 [#1] SMP PTI [ 332.344579] CPU: 2 PID: 25 Comm: kworker/2:0 Kdump: loaded Tainted: G O 4.18.0-rc3short-hpd-storm+ #2 [ 332.346453] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35 ) 09/14/2018 [ 332.348361] Workqueue: events intel_hpd_irq_storm_reenable_work [i915] [ 332.350301] RIP: 0010:intel_hpd_irq_storm_reenable_work.cold.3+0x2f/0x86 [i915] [ 332.352213] Code: 00 00 ba e8 00 00 00 48 c7 c6 c0 aa 5f a0 48 c7 c7 d0 73 62 a0 4c 89 c1 4c 89 04 24 e8 7f f5 af e0 4c 8b 04 24 44 89 f8 29 e8 <41> 39 80 ec 00 00 00 0f 85 43 13 fc ff 41 0f b6 86 b8 04 00 00 41 [ 332.354286] RSP: 0018:ffffc90000147e48 EFLAGS: 00010006 [ 332.356344] RAX: 0000000000000005 RBX: ffff8802c226c9d4 RCX: 0000000000000006 [ 332.358404] RDX: 0000000000000000 RSI: 0000000000000082 RDI: ffff88032dc95570 [ 332.360466] RBP: 0000000000000005 R08: 0000000000000000 R09: ffff88031b3dc840 [ 332.362528] R10: 0000000000000000 R11: 000000031a069602 R12: ffff8802c226ca20 [ 332.364575] R13: ffff8802c2268000 R14: ffff880310661000 R15: 000000000000000a [ 332.366615] FS: 0000000000000000(0000) GS:ffff88032dc80000(0000) knlGS:0000000000000000 [ 332.368658] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 332.370690] CR2: 00000000000000ec CR3: 000000000200a003 CR4: 00000000003606e0 [ 332.372724] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 332.374773] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 332.376798] Call Trace: [ 332.378809] process_one_work+0x1a1/0x350 [ 332.380806] worker_thread+0x30/0x380 [ 332.382777] ? wq_update_unbound_numa+0x10/0x10 [ 332.384772] kthread+0x112/0x130 [ 332.386740] ? kthread_create_worker_on_cpu+0x70/0x70 [ 332.388706] ret_from_fork+0x35/0x40 [ 332.390651] Modules linked in: i915(O) vfat fat joydev btusb btrtl btbcm btintel bluetooth ecdh_generic iTCO_wdt wmi_bmof i2c_algo_bit drm_kms_helper intel_rapl syscopyarea sysfillrect x86_pkg_temp_thermal sysimgblt coretemp fb_sys_fops crc32_pclmul drm psmouse pcspkr mei_me mei i2c_i801 lpc_ich mfd_core i2c_core tpm_tis tpm_tis_core thinkpad_acpi wmi tpm rfkill video crc32c_intel serio_raw ehci_pci xhci_pci ehci_hcd xhci_hcd [last unloaded: i915] [ 332.394963] CR2: 00000000000000ec This appears to be due to the fact that with an MST topology, not all intel_connector structs will have ->encoder set. So, fix this by skipping connectors without encoders in intel_hpd_irq_storm_reenable_work(). For those wondering, this bug was found on accident while simulating HPD storms using a Chamelium connected to a ThinkPad T450s (Broadwell). Changes since v1: - Check intel_connector->mst_port instead of intel_connector->encoder Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> --- drivers/gpu/drm/i915/intel_hotplug.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c index 648a13c6043c..8326900a311e 100644 --- a/drivers/gpu/drm/i915/intel_hotplug.c +++ b/drivers/gpu/drm/i915/intel_hotplug.c @@ -228,7 +228,9 @@ static void intel_hpd_irq_storm_reenable_work(struct work_struct *work) drm_for_each_connector_iter(connector, &conn_iter) { struct intel_connector *intel_connector = to_intel_connector(connector); - if (intel_connector->encoder->hpd_pin == pin) { + /* Don't check MST ports, they don't have pins */ + if (!intel_connector->mst_port && + intel_connector->encoder->hpd_pin == pin) { if (connector->polled != intel_connector->polled) DRM_DEBUG_DRIVER("Reenabling HPD on connector %s\n", connector->name); -- 2.19.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v3 3/5] drm/i915: Fix threshold check in intel_hpd_irq_storm_detect() 2018-11-03 0:19 [PATCH v3 0/5] drm/i915: HPD IRQ storm detection fixes Lyude Paul @ 2018-11-03 0:19 ` Lyude Paul 2018-11-03 0:19 ` [PATCH v3 2/5] drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST Lyude Paul ` (6 subsequent siblings) 7 siblings, 0 replies; 12+ messages in thread From: Lyude Paul @ 2018-11-03 0:19 UTC (permalink / raw) To: intel-gfx; +Cc: David Airlie, linux-kernel, dri-devel, Rodrigo Vivi Currently in intel_hpd_irq_storm_detect() when we detect that the last recorded hotplug wasn't within the period defined by HPD_STORM_DETECT_DELAY, we make the mistake of resetting the HPD count to 0 without incrementing it. This results in us only enabling storm detection when we go +2 above the threshold, e.g. an HPD threshold of 5 would not trigger a storm until we reach a total of 7 hotplugs. So: rework the code a bit so we reset the HPD count when HPD_STORM_DETECT_DELAY has passed, then increment the count afterwards. Also, clean things up a bit to make it easier to undertand. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> --- drivers/gpu/drm/i915/intel_hotplug.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c index 8326900a311e..c11d73de16f2 100644 --- a/drivers/gpu/drm/i915/intel_hotplug.c +++ b/drivers/gpu/drm/i915/intel_hotplug.c @@ -135,24 +135,27 @@ enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv, static bool intel_hpd_irq_storm_detect(struct drm_i915_private *dev_priv, enum hpd_pin pin) { - unsigned long start = dev_priv->hotplug.stats[pin].last_jiffies; + struct i915_hotplug *hpd = &dev_priv->hotplug; + unsigned long start = hpd->stats[pin].last_jiffies; unsigned long end = start + msecs_to_jiffies(HPD_STORM_DETECT_PERIOD); - const int threshold = dev_priv->hotplug.hpd_storm_threshold; + const int threshold = hpd->hpd_storm_threshold; bool storm = false; + if (!threshold) + return false; + if (!time_in_range(jiffies, start, end)) { - dev_priv->hotplug.stats[pin].last_jiffies = jiffies; - dev_priv->hotplug.stats[pin].count = 0; - DRM_DEBUG_KMS("Received HPD interrupt on PIN %d - cnt: 0\n", pin); - } else if (dev_priv->hotplug.stats[pin].count > threshold && - threshold) { - dev_priv->hotplug.stats[pin].state = HPD_MARK_DISABLED; + hpd->stats[pin].last_jiffies = jiffies; + hpd->stats[pin].count = 0; + } + + if (++hpd->stats[pin].count > threshold) { + hpd->stats[pin].state = HPD_MARK_DISABLED; DRM_DEBUG_KMS("HPD interrupt storm detected on PIN %d\n", pin); storm = true; } else { - dev_priv->hotplug.stats[pin].count++; DRM_DEBUG_KMS("Received HPD interrupt on PIN %d - cnt: %d\n", pin, - dev_priv->hotplug.stats[pin].count); + hpd->stats[pin].count); } return storm; -- 2.19.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v3 3/5] drm/i915: Fix threshold check in intel_hpd_irq_storm_detect() @ 2018-11-03 0:19 ` Lyude Paul 0 siblings, 0 replies; 12+ messages in thread From: Lyude Paul @ 2018-11-03 0:19 UTC (permalink / raw) To: intel-gfx Cc: Ville Syrjälä, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie, dri-devel, linux-kernel Currently in intel_hpd_irq_storm_detect() when we detect that the last recorded hotplug wasn't within the period defined by HPD_STORM_DETECT_DELAY, we make the mistake of resetting the HPD count to 0 without incrementing it. This results in us only enabling storm detection when we go +2 above the threshold, e.g. an HPD threshold of 5 would not trigger a storm until we reach a total of 7 hotplugs. So: rework the code a bit so we reset the HPD count when HPD_STORM_DETECT_DELAY has passed, then increment the count afterwards. Also, clean things up a bit to make it easier to undertand. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> --- drivers/gpu/drm/i915/intel_hotplug.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c index 8326900a311e..c11d73de16f2 100644 --- a/drivers/gpu/drm/i915/intel_hotplug.c +++ b/drivers/gpu/drm/i915/intel_hotplug.c @@ -135,24 +135,27 @@ enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv, static bool intel_hpd_irq_storm_detect(struct drm_i915_private *dev_priv, enum hpd_pin pin) { - unsigned long start = dev_priv->hotplug.stats[pin].last_jiffies; + struct i915_hotplug *hpd = &dev_priv->hotplug; + unsigned long start = hpd->stats[pin].last_jiffies; unsigned long end = start + msecs_to_jiffies(HPD_STORM_DETECT_PERIOD); - const int threshold = dev_priv->hotplug.hpd_storm_threshold; + const int threshold = hpd->hpd_storm_threshold; bool storm = false; + if (!threshold) + return false; + if (!time_in_range(jiffies, start, end)) { - dev_priv->hotplug.stats[pin].last_jiffies = jiffies; - dev_priv->hotplug.stats[pin].count = 0; - DRM_DEBUG_KMS("Received HPD interrupt on PIN %d - cnt: 0\n", pin); - } else if (dev_priv->hotplug.stats[pin].count > threshold && - threshold) { - dev_priv->hotplug.stats[pin].state = HPD_MARK_DISABLED; + hpd->stats[pin].last_jiffies = jiffies; + hpd->stats[pin].count = 0; + } + + if (++hpd->stats[pin].count > threshold) { + hpd->stats[pin].state = HPD_MARK_DISABLED; DRM_DEBUG_KMS("HPD interrupt storm detected on PIN %d\n", pin); storm = true; } else { - dev_priv->hotplug.stats[pin].count++; DRM_DEBUG_KMS("Received HPD interrupt on PIN %d - cnt: %d\n", pin, - dev_priv->hotplug.stats[pin].count); + hpd->stats[pin].count); } return storm; -- 2.19.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v3 4/5] drm/i915: Clarify flow for disabling IRQs on storms 2018-11-03 0:19 [PATCH v3 0/5] drm/i915: HPD IRQ storm detection fixes Lyude Paul ` (2 preceding siblings ...) 2018-11-03 0:19 ` Lyude Paul @ 2018-11-03 0:19 ` Lyude Paul 2018-11-05 20:38 ` Rodrigo Vivi 2018-11-03 0:19 ` [PATCH v3 5/5] drm/i915: Add short HPD IRQ storm detection for non-MST systems Lyude Paul ` (3 subsequent siblings) 7 siblings, 1 reply; 12+ messages in thread From: Lyude Paul @ 2018-11-03 0:19 UTC (permalink / raw) To: intel-gfx Cc: Ville Syrjälä, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie, dri-devel, linux-kernel This is rather confusing to look at as-is: dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler() handles disabling the actual HPD IRQ, while intel_hpd_irq_storm_disable() handles moving the HPD pin state over from MARK_DISABLED to DISABLED along with enabling polling for it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Lyude Paul <lyude@redhat.com> --- drivers/gpu/drm/i915/intel_hotplug.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c index c11d73de16f2..e5e3eeb7e482 100644 --- a/drivers/gpu/drm/i915/intel_hotplug.c +++ b/drivers/gpu/drm/i915/intel_hotplug.c @@ -351,7 +351,7 @@ static void i915_hotplug_work_func(struct work_struct *work) hpd_event_bits = dev_priv->hotplug.event_bits; dev_priv->hotplug.event_bits = 0; - /* Disable hotplug on connectors that hit an irq storm. */ + /* Enable polling for connectors which had HPD IRQ storms */ intel_hpd_irq_storm_disable(dev_priv); spin_unlock_irq(&dev_priv->irq_lock); @@ -458,6 +458,10 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv, } } + /* + * Disable any IRQs that storms were detected on. Polling enablement + * happens later in our hotplug work. + */ if (storm_detected && dev_priv->display_irqs_enabled) dev_priv->display.hpd_irq_setup(dev_priv); spin_unlock(&dev_priv->irq_lock); -- 2.19.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [Intel-gfx] [PATCH v3 4/5] drm/i915: Clarify flow for disabling IRQs on storms 2018-11-03 0:19 ` [PATCH v3 4/5] drm/i915: Clarify flow for disabling IRQs on storms Lyude Paul @ 2018-11-05 20:38 ` Rodrigo Vivi 0 siblings, 0 replies; 12+ messages in thread From: Rodrigo Vivi @ 2018-11-05 20:38 UTC (permalink / raw) To: Lyude Paul; +Cc: David Airlie, intel-gfx, linux-kernel, dri-devel On Fri, Nov 02, 2018 at 08:19:07PM -0400, Lyude Paul wrote: > This is rather confusing to look at as-is: > dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler() > handles disabling the actual HPD IRQ, while > intel_hpd_irq_storm_disable() handles moving the HPD pin state over from > MARK_DISABLED to DISABLED along with enabling polling for it. what about also changing the name of the function? > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Signed-off-by: Lyude Paul <lyude@redhat.com> > --- > drivers/gpu/drm/i915/intel_hotplug.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c > index c11d73de16f2..e5e3eeb7e482 100644 > --- a/drivers/gpu/drm/i915/intel_hotplug.c > +++ b/drivers/gpu/drm/i915/intel_hotplug.c > @@ -351,7 +351,7 @@ static void i915_hotplug_work_func(struct work_struct *work) > hpd_event_bits = dev_priv->hotplug.event_bits; > dev_priv->hotplug.event_bits = 0; > > - /* Disable hotplug on connectors that hit an irq storm. */ > + /* Enable polling for connectors which had HPD IRQ storms */ > intel_hpd_irq_storm_disable(dev_priv); This now gets confusing to my brain... comment says "enable" function name is "disable". > > spin_unlock_irq(&dev_priv->irq_lock); > @@ -458,6 +458,10 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv, > } > } > > + /* > + * Disable any IRQs that storms were detected on. Polling enablement > + * happens later in our hotplug work. > + */ > if (storm_detected && dev_priv->display_irqs_enabled) > dev_priv->display.hpd_irq_setup(dev_priv); > spin_unlock(&dev_priv->irq_lock); > -- > 2.19.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Intel-gfx] [PATCH v3 4/5] drm/i915: Clarify flow for disabling IRQs on storms @ 2018-11-05 20:38 ` Rodrigo Vivi 0 siblings, 0 replies; 12+ messages in thread From: Rodrigo Vivi @ 2018-11-05 20:38 UTC (permalink / raw) To: Lyude Paul; +Cc: intel-gfx, David Airlie, linux-kernel, dri-devel On Fri, Nov 02, 2018 at 08:19:07PM -0400, Lyude Paul wrote: > This is rather confusing to look at as-is: > dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler() > handles disabling the actual HPD IRQ, while > intel_hpd_irq_storm_disable() handles moving the HPD pin state over from > MARK_DISABLED to DISABLED along with enabling polling for it. what about also changing the name of the function? > > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> > Signed-off-by: Lyude Paul <lyude@redhat.com> > --- > drivers/gpu/drm/i915/intel_hotplug.c | 6 +++++- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c > index c11d73de16f2..e5e3eeb7e482 100644 > --- a/drivers/gpu/drm/i915/intel_hotplug.c > +++ b/drivers/gpu/drm/i915/intel_hotplug.c > @@ -351,7 +351,7 @@ static void i915_hotplug_work_func(struct work_struct *work) > hpd_event_bits = dev_priv->hotplug.event_bits; > dev_priv->hotplug.event_bits = 0; > > - /* Disable hotplug on connectors that hit an irq storm. */ > + /* Enable polling for connectors which had HPD IRQ storms */ > intel_hpd_irq_storm_disable(dev_priv); This now gets confusing to my brain... comment says "enable" function name is "disable". > > spin_unlock_irq(&dev_priv->irq_lock); > @@ -458,6 +458,10 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv, > } > } > > + /* > + * Disable any IRQs that storms were detected on. Polling enablement > + * happens later in our hotplug work. > + */ > if (storm_detected && dev_priv->display_irqs_enabled) > dev_priv->display.hpd_irq_setup(dev_priv); > spin_unlock(&dev_priv->irq_lock); > -- > 2.19.1 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v3 5/5] drm/i915: Add short HPD IRQ storm detection for non-MST systems 2018-11-03 0:19 [PATCH v3 0/5] drm/i915: HPD IRQ storm detection fixes Lyude Paul ` (3 preceding siblings ...) 2018-11-03 0:19 ` [PATCH v3 4/5] drm/i915: Clarify flow for disabling IRQs on storms Lyude Paul @ 2018-11-03 0:19 ` Lyude Paul 2018-11-03 0:37 ` ✗ Fi.CI.SPARSE: warning for drm/i915: HPD IRQ storm detection fixes (rev3) Patchwork ` (2 subsequent siblings) 7 siblings, 0 replies; 12+ messages in thread From: Lyude Paul @ 2018-11-03 0:19 UTC (permalink / raw) To: intel-gfx Cc: Ville Syrjälä, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, David Airlie, dri-devel, linux-kernel Unfortunately, it seems that the HPD IRQ storm problem from the early days of Intel GPUs was never entirely solved, only mostly. Within the last couple of days, I got a bug report from one of our customers who had been having issues with their machine suddenly booting up very slowly after having updated. The amount of time it took to boot went from around 30 seconds, to over 6 minutes consistently. After some investigation, I discovered that i915 was reporting massive amounts of short HPD IRQ spam on this system from the DisplayPort port, despite there not being anything actually connected. The symptoms would start with one "long" HPD IRQ being detected at boot: [ 1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00440000, dig 0x00440000, pins 0x000000a0 [ 1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long [ 1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 5 - cnt: 0 [ 1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long [ 1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 7 - cnt: 0 [ 1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long [ 1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long … followed by constant short IRQs afterwards: [ 1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status updated from unknown to disconnected [ 1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) received hotplug event. [ 1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3] [ 1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 0x71450085 [ 1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 [ 1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short [ 1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 0x00200000, dig 0x00200000, pins 0x00000080 The customer's system in question has a GM45 GPU, which is apparently well known for hotplugging storms. So, workaround this impressively broken hardware by changing the default HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and short IRQs count for 1. This makes it so that 5 long IRQs will trigger an HPD storm, and on systems with short HPD storm detection 50 short IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of constant pulsing, which seems like a good middleground between being too sensitive and not being sensitive enough (which would cause visible stutters in userspace every time a storm occurs). And just to be extra safe: we don't enable this by default on systems with MST support. There's too high of a chance of MST support triggering storm detection, and systems that are new enough to support MST are a lot less likely to have issues with IRQ storms anyway. As a note: this patch was tested using a ThinkPad T450s and a Chamelium to simulate the short IRQ storms. Changes since v1: - Don't use two separate thresholds, just make long IRQs count for 10 each and short IRQs count for 1. This simplifies the code a bit - Ville Syrjälä Changes since v2: - Document @long_hpd in intel_hpd_irq_storm_detect, no functional changes Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> --- drivers/gpu/drm/i915/i915_debugfs.c | 74 ++++++++++++++++++++++++++++ drivers/gpu/drm/i915/i915_drv.h | 5 +- drivers/gpu/drm/i915/i915_irq.c | 7 +++ drivers/gpu/drm/i915/intel_hotplug.c | 49 ++++++++++-------- 4 files changed, 114 insertions(+), 21 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 1a4d9d996fda..b9d6e1be6052 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4658,6 +4658,79 @@ static const struct file_operations i915_hpd_storm_ctl_fops = { .write = i915_hpd_storm_ctl_write }; +static int i915_hpd_short_storm_ctl_show(struct seq_file *m, void *data) +{ + struct drm_i915_private *dev_priv = m->private; + + seq_printf(m, "Enabled: %s\n", + yesno(dev_priv->hotplug.hpd_short_storm_enabled)); + + return 0; +} + +static int +i915_hpd_short_storm_ctl_open(struct inode *inode, struct file *file) +{ + return single_open(file, i915_hpd_short_storm_ctl_show, + inode->i_private); +} + +static ssize_t i915_hpd_short_storm_ctl_write(struct file *file, + const char __user *ubuf, + size_t len, loff_t *offp) +{ + struct seq_file *m = file->private_data; + struct drm_i915_private *dev_priv = m->private; + struct i915_hotplug *hotplug = &dev_priv->hotplug; + char *newline; + char tmp[16]; + int i; + bool new_state; + + if (len >= sizeof(tmp)) + return -EINVAL; + + if (copy_from_user(tmp, ubuf, len)) + return -EFAULT; + + tmp[len] = '\0'; + + /* Strip newline, if any */ + newline = strchr(tmp, '\n'); + if (newline) + *newline = '\0'; + + /* Reset to the "default" state for this system */ + if (strcmp(tmp, "reset") == 0) + new_state = !HAS_DP_MST(dev_priv); + else if (kstrtobool(tmp, &new_state) != 0) + return -EINVAL; + + DRM_DEBUG_KMS("%sabling HPD short storm detection\n", + new_state ? "En" : "Dis"); + + spin_lock_irq(&dev_priv->irq_lock); + hotplug->hpd_short_storm_enabled = new_state; + /* Reset the HPD storm stats so we don't accidentally trigger a storm */ + for_each_hpd_pin(i) + hotplug->stats[i].count = 0; + spin_unlock_irq(&dev_priv->irq_lock); + + /* Re-enable hpd immediately if we were in an irq storm */ + flush_delayed_work(&dev_priv->hotplug.reenable_work); + + return len; +} + +static const struct file_operations i915_hpd_short_storm_ctl_fops = { + .owner = THIS_MODULE, + .open = i915_hpd_short_storm_ctl_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, + .write = i915_hpd_short_storm_ctl_write, +}; + static int i915_drrs_ctl_set(void *data, u64 val) { struct drm_i915_private *dev_priv = data; @@ -4865,6 +4938,7 @@ static const struct i915_debugfs_files { {"i915_guc_log_level", &i915_guc_log_level_fops}, {"i915_guc_log_relay", &i915_guc_log_relay_fops}, {"i915_hpd_storm_ctl", &i915_hpd_storm_ctl_fops}, + {"i915_hpd_short_storm_ctl", &i915_hpd_short_storm_ctl_fops}, {"i915_ipc_status", &i915_ipc_status_fops}, {"i915_drrs_ctl", &i915_drrs_ctl_fops}, {"i915_edp_psr_debug", &i915_edp_psr_debug_fops} diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 2a88a7eb871b..0c8438de3c1b 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -283,7 +283,8 @@ enum hpd_pin { #define for_each_hpd_pin(__pin) \ for ((__pin) = (HPD_NONE + 1); (__pin) < HPD_NUM_PINS; (__pin)++) -#define HPD_STORM_DEFAULT_THRESHOLD 5 +/* Threshold == 5 for long IRQs, 50 for short */ +#define HPD_STORM_DEFAULT_THRESHOLD 50 struct i915_hotplug { struct work_struct hotplug_work; @@ -308,6 +309,8 @@ struct i915_hotplug { bool poll_enabled; unsigned int hpd_storm_threshold; + /* Whether or not to count short HPD IRQs in HPD storms */ + u8 hpd_short_storm_enabled; /* * if we get a HPD irq from DP and a HPD irq from non-DP diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 5d1f53723388..d7e47d6082de 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -4863,6 +4863,13 @@ void intel_irq_init(struct drm_i915_private *dev_priv) dev_priv->display_irqs_enabled = false; dev_priv->hotplug.hpd_storm_threshold = HPD_STORM_DEFAULT_THRESHOLD; + /* If we have MST support, we want to avoid doing short HPD IRQ storm + * detection, as short HPD storms will occur as a natural part of + * sideband messaging with MST. + * On older platforms however, IRQ storms can occur with both long and + * short pulses, as seen on some G4x systems. + */ + dev_priv->hotplug.hpd_short_storm_enabled = !HAS_DP_MST(dev_priv); dev->driver->get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos; dev->driver->get_scanout_position = i915_get_crtc_scanoutpos; diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c index e5e3eeb7e482..3039257ec2c5 100644 --- a/drivers/gpu/drm/i915/intel_hotplug.c +++ b/drivers/gpu/drm/i915/intel_hotplug.c @@ -114,34 +114,46 @@ enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv, #define HPD_STORM_REENABLE_DELAY (2 * 60 * 1000) /** - * intel_hpd_irq_storm_detect - gather stats and detect HPD irq storm on a pin + * intel_hpd_irq_storm_detect - gather stats and detect HPD IRQ storm on a pin * @dev_priv: private driver data pointer * @pin: the pin to gather stats on + * @long_hpd: whether the HPD IRQ was long or short * - * Gather stats about HPD irqs from the specified @pin, and detect irq + * Gather stats about HPD IRQs from the specified @pin, and detect IRQ * storms. Only the pin specific stats and state are changed, the caller is * responsible for further action. * - * The number of irqs that are allowed within @HPD_STORM_DETECT_PERIOD is + * The number of IRQs that are allowed within @HPD_STORM_DETECT_PERIOD is * stored in @dev_priv->hotplug.hpd_storm_threshold which defaults to - * @HPD_STORM_DEFAULT_THRESHOLD. If this threshold is exceeded, it's - * considered an irq storm and the irq state is set to @HPD_MARK_DISABLED. + * @HPD_STORM_DEFAULT_THRESHOLD. Long IRQs count as +10 to this threshold, and + * short IRQs count as +1. If this threshold is exceeded, it's considered an + * IRQ storm and the IRQ state is set to @HPD_MARK_DISABLED. + * + * By default, most systems will only count long IRQs towards + * &dev_priv->hotplug.hpd_storm_threshold. However, some older systems also + * suffer from short IRQ storms and must also track these. Because short IRQ + * storms are naturally caused by sideband interactions with DP MST devices, + * short IRQ detection is only enabled for systems without DP MST support. + * Systems which are new enough to support DP MST are far less likely to + * suffer from IRQ storms at all, so this is fine. * * The HPD threshold can be controlled through i915_hpd_storm_ctl in debugfs, * and should only be adjusted for automated hotplug testing. * - * Return true if an irq storm was detected on @pin. + * Return true if an IRQ storm was detected on @pin. */ static bool intel_hpd_irq_storm_detect(struct drm_i915_private *dev_priv, - enum hpd_pin pin) + enum hpd_pin pin, bool long_hpd) { struct i915_hotplug *hpd = &dev_priv->hotplug; unsigned long start = hpd->stats[pin].last_jiffies; unsigned long end = start + msecs_to_jiffies(HPD_STORM_DETECT_PERIOD); + const int increment = long_hpd ? 10 : 1; const int threshold = hpd->hpd_storm_threshold; bool storm = false; - if (!threshold) + if (!threshold || + (!long_hpd && !dev_priv->hotplug.hpd_short_storm_enabled)) return false; if (!time_in_range(jiffies, start, end)) { @@ -149,7 +161,8 @@ static bool intel_hpd_irq_storm_detect(struct drm_i915_private *dev_priv, hpd->stats[pin].count = 0; } - if (++hpd->stats[pin].count > threshold) { + hpd->stats[pin].count += increment; + if (hpd->stats[pin].count > threshold) { hpd->stats[pin].state = HPD_MARK_DISABLED; DRM_DEBUG_KMS("HPD interrupt storm detected on PIN %d\n", pin); storm = true; @@ -408,28 +421,24 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv, for_each_intel_encoder(&dev_priv->drm, encoder) { enum hpd_pin pin = encoder->hpd_pin; bool has_hpd_pulse = intel_encoder_has_hpd_pulse(encoder); + bool long_hpd = true; if (!(BIT(pin) & pin_mask)) continue; if (has_hpd_pulse) { - bool long_hpd = long_mask & BIT(pin); enum port port = encoder->port; + long_hpd = !!(long_mask & BIT(pin)); + DRM_DEBUG_DRIVER("digital hpd port %c - %s\n", port_name(port), long_hpd ? "long" : "short"); - /* - * For long HPD pulses we want to have the digital queue happen, - * but we still want HPD storm detection to function. - */ queue_dig = true; - if (long_hpd) { + if (long_hpd) dev_priv->hotplug.long_port_mask |= (1 << port); - } else { - /* for short HPD just trigger the digital queue */ + else dev_priv->hotplug.short_port_mask |= (1 << port); - continue; - } + } if (dev_priv->hotplug.stats[pin].state == HPD_DISABLED) { @@ -452,7 +461,7 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv, queue_hp = true; } - if (intel_hpd_irq_storm_detect(dev_priv, pin)) { + if (intel_hpd_irq_storm_detect(dev_priv, pin, long_hpd)) { dev_priv->hotplug.event_bits &= ~BIT(pin); storm_detected = true; } -- 2.19.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* ✗ Fi.CI.SPARSE: warning for drm/i915: HPD IRQ storm detection fixes (rev3) 2018-11-03 0:19 [PATCH v3 0/5] drm/i915: HPD IRQ storm detection fixes Lyude Paul ` (4 preceding siblings ...) 2018-11-03 0:19 ` [PATCH v3 5/5] drm/i915: Add short HPD IRQ storm detection for non-MST systems Lyude Paul @ 2018-11-03 0:37 ` Patchwork 2018-11-03 0:53 ` ✓ Fi.CI.BAT: success " Patchwork 2018-11-03 4:18 ` ✓ Fi.CI.IGT: " Patchwork 7 siblings, 0 replies; 12+ messages in thread From: Patchwork @ 2018-11-03 0:37 UTC (permalink / raw) To: Lyude Paul; +Cc: intel-gfx == Series Details == Series: drm/i915: HPD IRQ storm detection fixes (rev3) URL : https://patchwork.freedesktop.org/series/51556/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Fix possible race in intel_dp_add_mst_connector() Okay! Commit: drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST Okay! Commit: drm/i915: Fix threshold check in intel_hpd_irq_storm_detect() Okay! Commit: drm/i915: Clarify flow for disabling IRQs on storms Okay! Commit: drm/i915: Add short HPD IRQ storm detection for non-MST systems -drivers/gpu/drm/i915/selftests/../i915_drv.h:3705:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3708:16: warning: expression using sizeof(void) _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 12+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915: HPD IRQ storm detection fixes (rev3) 2018-11-03 0:19 [PATCH v3 0/5] drm/i915: HPD IRQ storm detection fixes Lyude Paul ` (5 preceding siblings ...) 2018-11-03 0:37 ` ✗ Fi.CI.SPARSE: warning for drm/i915: HPD IRQ storm detection fixes (rev3) Patchwork @ 2018-11-03 0:53 ` Patchwork 2018-11-03 4:18 ` ✓ Fi.CI.IGT: " Patchwork 7 siblings, 0 replies; 12+ messages in thread From: Patchwork @ 2018-11-03 0:53 UTC (permalink / raw) To: Lyude Paul; +Cc: intel-gfx == Series Details == Series: drm/i915: HPD IRQ storm detection fixes (rev3) URL : https://patchwork.freedesktop.org/series/51556/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5082 -> Patchwork_10720 = == Summary - WARNING == Minor unknown changes coming with Patchwork_10720 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10720, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/51556/revisions/3/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10720: === IGT changes === ==== Warnings ==== igt@pm_rpm@module-reload: fi-hsw-4770r: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_10720 that come from known issues: === IGT changes === ==== Issues hit ==== igt@drv_module_reload@basic-reload-inject: fi-hsw-4770r: PASS -> DMESG-WARN (fdo#107425, fdo#107924) igt@drv_selftest@live_execlists: fi-apl-guc: PASS -> INCOMPLETE (fdo#103927, fdo#106693) igt@gem_exec_suspend@basic-s3: fi-kbl-soraka: NOTRUN -> INCOMPLETE (fdo#107774, fdo#107556, fdo#107859) igt@prime_vgem@basic-fence-flip: fi-cfl-8700k: PASS -> FAIL (fdo#104008) ==== Possible fixes ==== igt@kms_flip@basic-flip-vs-dpms: fi-skl-6700hq: DMESG-WARN (fdo#105998) -> PASS igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: FAIL (fdo#103167) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: fi-cfl-8109u: INCOMPLETE (fdo#106070, fdo#108126) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fdo#105998 https://bugs.freedesktop.org/show_bug.cgi?id=105998 fdo#106070 https://bugs.freedesktop.org/show_bug.cgi?id=106070 fdo#106693 https://bugs.freedesktop.org/show_bug.cgi?id=106693 fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425 fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107774 https://bugs.freedesktop.org/show_bug.cgi?id=107774 fdo#107859 https://bugs.freedesktop.org/show_bug.cgi?id=107859 fdo#107924 https://bugs.freedesktop.org/show_bug.cgi?id=107924 fdo#108126 https://bugs.freedesktop.org/show_bug.cgi?id=108126 == Participating hosts (50 -> 44) == Additional (1): fi-kbl-soraka Missing (7): fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-gdg-551 == Build changes == * Linux: CI_DRM_5082 -> Patchwork_10720 CI_DRM_5082: 71cc71176de66cc725595a436f761f183a8b9ca7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4706: 5421c73a7db3cfaa85ab24325fe6e898cbb27fb3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10720: c09ca9624feda6f8d963e5a085056fbc6fb92202 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c09ca9624fed drm/i915: Add short HPD IRQ storm detection for non-MST systems 0d11bfe6ec1c drm/i915: Clarify flow for disabling IRQs on storms c3d529fb232c drm/i915: Fix threshold check in intel_hpd_irq_storm_detect() d44d4e697a61 drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST a7f26c0167e3 drm/i915: Fix possible race in intel_dp_add_mst_connector() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10720/issues.html _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 12+ messages in thread
* ✓ Fi.CI.IGT: success for drm/i915: HPD IRQ storm detection fixes (rev3) 2018-11-03 0:19 [PATCH v3 0/5] drm/i915: HPD IRQ storm detection fixes Lyude Paul ` (6 preceding siblings ...) 2018-11-03 0:53 ` ✓ Fi.CI.BAT: success " Patchwork @ 2018-11-03 4:18 ` Patchwork 7 siblings, 0 replies; 12+ messages in thread From: Patchwork @ 2018-11-03 4:18 UTC (permalink / raw) To: Lyude Paul; +Cc: intel-gfx == Series Details == Series: drm/i915: HPD IRQ storm detection fixes (rev3) URL : https://patchwork.freedesktop.org/series/51556/ State : success == Summary == = CI Bug Log - changes from CI_DRM_5082_full -> Patchwork_10720_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10720_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10720_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10720_full: === IGT changes === ==== Warnings ==== igt@kms_plane@plane-panning-bottom-right-pipe-b-planes: shard-snb: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_10720_full that come from known issues: === IGT changes === ==== Issues hit ==== igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a: shard-skl: NOTRUN -> DMESG-WARN (fdo#107956) +1 igt@kms_cursor_crc@cursor-128x42-random: shard-glk: PASS -> FAIL (fdo#103232) +3 igt@kms_cursor_crc@cursor-64x64-dpms: shard-apl: PASS -> FAIL (fdo#103232) igt@kms_cursor_legacy@cursorb-vs-flipb-toggle: shard-glk: PASS -> DMESG-WARN (fdo#105763, fdo#106538) igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-mmap-wc: shard-glk: PASS -> FAIL (fdo#103167) +2 igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render: shard-apl: PASS -> FAIL (fdo#103167) igt@kms_plane_alpha_blend@pipe-a-alpha-transparant-fb: shard-skl: NOTRUN -> FAIL (fdo#108145) +1 igt@kms_plane_multiple@atomic-pipe-a-tiling-y: shard-apl: PASS -> FAIL (fdo#103166) +2 igt@kms_plane_multiple@atomic-pipe-b-tiling-y: shard-glk: PASS -> FAIL (fdo#103166) +1 ==== Possible fixes ==== igt@drv_suspend@debugfs-reader: shard-kbl: INCOMPLETE (fdo#103665) -> PASS igt@kms_available_modes_crc@available_mode_test_crc: shard-apl: FAIL (fdo#106641) -> PASS igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-b: shard-kbl: DMESG-WARN (fdo#107956) -> PASS igt@kms_cursor_crc@cursor-128x42-onscreen: shard-apl: FAIL (fdo#103232) -> PASS +1 igt@kms_cursor_crc@cursor-64x64-dpms: shard-glk: FAIL (fdo#103232) -> PASS +1 igt@kms_draw_crc@draw-method-xrgb2101010-pwrite-untiled: shard-skl: FAIL (fdo#103184) -> PASS igt@kms_flip@flip-vs-expired-vblank-interruptible: shard-skl: FAIL (fdo#105363) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu: shard-apl: FAIL (fdo#103167) -> PASS igt@kms_frontbuffer_tracking@fbc-1p-rte: shard-apl: FAIL (fdo#103167, fdo#105682) -> PASS igt@kms_frontbuffer_tracking@fbc-2p-primscrn-cur-indfb-draw-mmap-cpu: shard-glk: FAIL (fdo#103167) -> PASS +3 igt@kms_frontbuffer_tracking@psr-rgb101010-draw-pwrite: shard-skl: FAIL (fdo#103167) -> PASS +3 igt@kms_pipe_crc_basic@read-crc-pipe-a: shard-skl: FAIL (fdo#107362) -> PASS igt@kms_plane_multiple@atomic-pipe-c-tiling-yf: shard-apl: FAIL (fdo#103166) -> PASS +1 igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS shard-kbl: FAIL (fdo#99912) -> PASS igt@perf@blocking: shard-hsw: FAIL (fdo#102252) -> PASS fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252 fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103184 https://bugs.freedesktop.org/show_bug.cgi?id=103184 fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232 fdo#103665 https://bugs.freedesktop.org/show_bug.cgi?id=103665 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105682 https://bugs.freedesktop.org/show_bug.cgi?id=105682 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538 fdo#106641 https://bugs.freedesktop.org/show_bug.cgi?id=106641 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107956 https://bugs.freedesktop.org/show_bug.cgi?id=107956 fdo#108145 https://bugs.freedesktop.org/show_bug.cgi?id=108145 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (6 -> 6) == No changes in participating hosts == Build changes == * Linux: CI_DRM_5082 -> Patchwork_10720 CI_DRM_5082: 71cc71176de66cc725595a436f761f183a8b9ca7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4706: 5421c73a7db3cfaa85ab24325fe6e898cbb27fb3 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10720: c09ca9624feda6f8d963e5a085056fbc6fb92202 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10720/shards.html _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-11-05 20:38 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-11-03 0:19 [PATCH v3 0/5] drm/i915: HPD IRQ storm detection fixes Lyude Paul 2018-11-03 0:19 ` [PATCH v3 1/5] drm/i915: Fix possible race in intel_dp_add_mst_connector() Lyude Paul 2018-11-03 0:19 ` [PATCH v3 2/5] drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST Lyude Paul 2018-11-03 0:19 ` [PATCH v3 3/5] drm/i915: Fix threshold check in intel_hpd_irq_storm_detect() Lyude Paul 2018-11-03 0:19 ` Lyude Paul 2018-11-03 0:19 ` [PATCH v3 4/5] drm/i915: Clarify flow for disabling IRQs on storms Lyude Paul 2018-11-05 20:38 ` [Intel-gfx] " Rodrigo Vivi 2018-11-05 20:38 ` Rodrigo Vivi 2018-11-03 0:19 ` [PATCH v3 5/5] drm/i915: Add short HPD IRQ storm detection for non-MST systems Lyude Paul 2018-11-03 0:37 ` ✗ Fi.CI.SPARSE: warning for drm/i915: HPD IRQ storm detection fixes (rev3) Patchwork 2018-11-03 0:53 ` ✓ Fi.CI.BAT: success " Patchwork 2018-11-03 4:18 ` ✓ Fi.CI.IGT: " Patchwork
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.