intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Egbert Eich <eich@freedesktop.org>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Egbert Eich <eich@suse.de>,
	Daniel Vetter <daniel.vetter@intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 1/7] drm/i915: Add HPD IRQ storm detection (v4)
Date: Tue, 16 Apr 2013 11:50:22 +0200	[thread overview]
Message-ID: <20130416095022.GC17947@debian> (raw)
In-Reply-To: <87hajdpg42.fsf@intel.com>

Hi Jani,

On Thu, Apr 11, 2013 at 12:32:29PM +0300, Jani Nikula wrote:
> 
> Hi Egbert -
> 
> Up front, I haven't been following this series or read any of the
> previous review comments. Please bear with me, and feel free to direct
> me to earlier comments if I'm in contradiction.

Sorry for the late reply - last week I was quite busy with other stuff,
this week i'm a bit preoccupied.

> 
> On Tue, 09 Apr 2013, Egbert Eich <eich@freedesktop.org> wrote:
> > From: Egbert Eich <eich@suse.de>
> >
> > Add a hotplug IRQ storm detection (triggered when a hotplug interrupt
> > fires more than 5 times / sec).
> 
> Okay, this is theoretical, but a display port sink could do more than
> that many hpd irq requests when connected. Which leads me to wonder in
> general if the storm detection should be different for hot plug
> vs. unplug and hpd irq events.

Agreed. 
During my tests I did not see any issues with the statistics I've 
implemented: 5/sec was an ad-hoc choice and I wanted to start with 
something simple.
I've tested it and it seemed to work, so I didn't bother to look into
this more deeply, however if you feel 5 events  / sec are too few to
really do a good distinction, we could easily increase this number.

There have been two situations where I have seen 'interrupt storms':

1. On G35: some boxes of the affected systems do not show this issue 
   at all while others see a very high load but are still usable.
   In my recollection there were in the order of some 100 interrupts/sec
   on these machines. Then there were systems which would 'stall' in
   the worker during boot due to high load. At one point the NMI 
   watchdog kicked in and stopped this mess. There the interrupts
   happened at an order of magnitude if 10k!

2. A laptop with a Sandybridge chipset where the system load went
   high at certain stages of charging levels - when the power supply
   was connected. I would assume the frequency there also was around
   some 100 / sec.

Thus if we increase the threshold frequency to some 10 / sec we
would still cover all those cases.

Some other issue I've seen is 'bouncing' during manual plugging
I've been contemplating how to address this. There are two things 
to look at:
1. multiple hotplug events due to not getting a perfect connection at first
2. EDID readout happening to early when the EDID lines are not yet fully
   and 'permanently' connected.
It might well be, that a fix for these issues might actually also adress 
the issues you are pointing out.

I have not seen them on Intel hardware - but this may be due to the 
fact that the hardware I saw it on was a separate gfx card which did 
not have the usual mounting bracket and thus the entire setup was a 
bit fragile and not really suitable for hot-plugging.
However I believe that these things might happen everywere for people
not quite used to plugging monitors too much.

> 
> Have you observed difference between hot plug/unplug?

There seems to be a difference between monitor connected/not connected:

On DVI (G35) one doesn't distinguish between plug/unplug: when the hotplug
line on the connector changes state an interrupt is sent. On this system
storms only happened when a monitor was conneted - since the state of the
HPD pin is signalled thru different frequencies on a line across SDVO (in 
my recollection it was 10 vs. 20 MHz) I believe that due to cross talk
the higher(?) frequency could not always reliably be measured.

I did not have access to the laptop system and the customer was not 
patient enough to help me to debug this further with me.

Generally I think we would still adress the 'strom condition' if we
raised the threshold to 20 or 30 /sec.

What do you think?

> 
> Has this been a problem on PCH split platforms, i.e. since ilk/gen5?

I've also observed this on Sandybridge - which would be past GEN5, 
wouldn't it?

I will address some of the other issues mentioned in a new patch.

Thanks a lot for looking at it!

Cheers,
	Egbert.

  parent reply	other threads:[~2013-04-16  9:51 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-09  9:24 [PATCH v3 0/7] Add HPD interrupt storm detection Egbert Eich
2013-04-09  9:24 ` [PATCH v3 1/7] drm/i915: Add HPD IRQ storm detection (v4) Egbert Eich
2013-04-11  9:32   ` Jani Nikula
2013-04-11 10:46     ` Daniel Vetter
2013-04-16  9:50     ` Egbert Eich [this message]
2013-04-16 11:34     ` Egbert Eich
2013-04-16 11:36       ` [PATCH 1/7] drm/i915: Add HPD IRQ storm detection (v5) Egbert Eich
2013-04-16 11:36         ` [PATCH 2/7] drm/i915: (re)init HPD interrupt storm statistics Egbert Eich
2013-04-16 11:36         ` [PATCH 3/7] drm/i915: Mask out the HPD irq bits before setting them individually Egbert Eich
2013-04-16 11:36         ` [PATCH 4/7] drm/i915: Disable HPD interrupt on pin when irq storm is detected (v3) Egbert Eich
2013-04-16 11:36         ` [PATCH 5/7] drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4) Egbert Eich
2013-04-16 18:07           ` Daniel Vetter
2013-04-16 20:22             ` Egbert Eich
2013-04-16 20:26               ` Daniel Vetter
2013-04-16 11:36         ` [PATCH 6/7] drm/i915: Add bit field to record which pins have received HPD events (v3) Egbert Eich
2013-04-16 11:37         ` [PATCH 7/7] drm/i915: Only reprobe display on encoder which has received an HPD event (v2) Egbert Eich
2013-04-09  9:24 ` [PATCH v3 2/7] drm/i915: (re)init HPD interrupt storm statistics Egbert Eich
2013-04-11  9:54   ` Jani Nikula
2013-04-09  9:24 ` [PATCH v3 3/7] drm/i915: Mask out the HPD irq bits before setting them individually Egbert Eich
2013-04-11  9:56   ` Jani Nikula
2013-04-09  9:24 ` [PATCH v3 4/7] drm/i915: Disable HPD interrupt on pin when irq storm is detected (v2) Egbert Eich
2013-04-11 10:13   ` Jani Nikula
2013-04-11 13:25     ` [PATCH v3] drm/i915: Disable HPD interrupt on pin when irq storm is detected (v3) Egbert Eich
2013-04-11 14:20       ` Jani Nikula
2013-04-09  9:24 ` [PATCH v3 5/7] drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v3) Egbert Eich
2013-04-11 10:44   ` Jani Nikula
2013-04-11 13:10     ` Egbert Eich
2013-04-11 14:48       ` Jani Nikula
2013-04-11 13:28     ` [PATCH v4] drm/i915: Add Reenable Timer to turn Hotplug Detection back on (v4) Egbert Eich
2013-04-11 14:30       ` Jani Nikula
2013-04-09  9:24 ` [PATCH v3 6/7] drm/i915: Add bit field to record which pins have received HPD events (v2) Egbert Eich
2013-04-11 13:21   ` Jani Nikula
2013-04-11 13:34     ` Egbert Eich
2013-04-11 13:57     ` [PATCH v3] drm/i915: Add bit field to record which pins have received HPD events (v3) Egbert Eich
2013-04-11 14:03       ` [PATCH v3 Update] " Egbert Eich
2013-04-11 15:00         ` Jani Nikula
2013-04-09  9:24 ` [PATCH v3 7/7] drm/i915: Only reprobe display on encoder which has received an HPD event Egbert Eich
2013-04-11 13:35   ` Jani Nikula
     [not found] <Message-ID: <87wqs9nqbb.fsf@intel.com>
2013-04-11 14:00 ` [PATCH v2] drm/i915: Only reprobe display on encoder which has received an HPD event (v2) Egbert Eich
2013-04-11 15:06   ` Jani Nikula
2013-04-23 12:26     ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130416095022.GC17947@debian \
    --to=eich@freedesktop.org \
    --cc=daniel.vetter@intel.com \
    --cc=eich@suse.de \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).