[Intel-gfx] [PATCH 0/8] Detect and deal with Interrupt 'Storms' from noisy Hotplug Lines.

Egbert Eich eich at suse.de
Thu Jan 10 16:02:38 CET 2013


Despite the many attempts to fix the issue with noisy hotplug interrupt lines
we are still seeing systems that suffer from this:
Recently we encountered a rather large scale installation of Q35 systems
which was hit by this issue rather severely: It seemed as if not all machines
of the same model were hit equally bad, in the worst cased hotplug
interrupt noise caused several 1000 interrupts / s. Those machines would not
even boot, instead the interrupt handler and the scheduled workers would keep
the CPU  busy that eventually the watchdog would kick in and issue an NMI.
Other machines only received severa 10s to 100s of interrupts per sec - those
machines would run properly - just with an excessive system load.
More thorough investigations seemed to indicate that this condition
only happen at certain video modes.

On another system - a laptop - a hotplug interrupt 'storm' occurred when 
it was charging and the batteries were at certain charge levels. While 
the system was still running fine its load was high enough that the user
noticed from the fan noise that a problem existed.
The latter system had a Sandybridge chipset, thus a totally different 
generation from the former.

All those cases seemed to have been caused by cross talk on badly routed 
hotplug signal lines (or voltage instabilities).
This led to the conclusion that instead of trying to work around these
'storms' for each individual system, there should be a generic way to detect 
such a condition and take appropriate action:

This patch series implements a hotplug 'storm' detection, disables the
respective interrupt for the hotplug pin when this condition is detected
and reverts to periodic output polling on the affected connector.
After a grace period of 2 minutes it will reenable hotplug on the affected
line. This will take care of cases in which this condition is only temporary.
Should the 'storm' condtion persist, this cycle will start over again.

To implement this some rearrangements in the code were required:
- The interrupt status bit which signals a hotplug needed to be recorded
  for each connector.
- The interrupt enable functions needed to be separate, also they need 
  to be able to enable interrupts for each hotplug line independently.


Egbert Eich (8):
  drm/i915: Remove pch_rq_mask from struct drm_i915_private.
  drm/i915: Set hotplug_supported_flag for all chipset generations.
  drm/i915: Add hpd status bit to struct intel_connector.
  drm/i915: Add Hotplug IRQ Storm detection.
  drm/i915: Move hotplug interrupt enable for i915/i965/valleyview into
    a separate function.
  drm/i915: Only enable hotplug irq when needed on Ironlake and later
    chips.
  drm/i915: When detecting a hotplug IRQ storm disable respective IRQs.
  drm/i915: Add Reenable Timer to turn Hotplug Detection back on.

 drivers/gpu/drm/i915/i915_drv.h   |    7 +-
 drivers/gpu/drm/i915/i915_irq.c   |  475 +++++++++++++++++++++++++++----------
 drivers/gpu/drm/i915/intel_crt.c  |    3 +-
 drivers/gpu/drm/i915/intel_dp.c   |    5 +-
 drivers/gpu/drm/i915/intel_drv.h  |   11 +
 drivers/gpu/drm/i915/intel_hdmi.c |    5 +-
 drivers/gpu/drm/i915/intel_sdvo.c |   23 +-
 7 files changed, 383 insertions(+), 146 deletions(-)

-- 
1.7.7




More information about the Intel-gfx mailing list