From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org
Cc: Hans de Goede <hdegoede@redhat.com>
Subject: Re: [PATCH v2 01/11] drm/i915: Disable preemption and sleeping while using the punit sideband
Date: Tue, 16 Jan 2018 17:27:42 +0200 [thread overview]
Message-ID: <87tvvlj029.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <151601843495.8139.2479446032422799761@mail.alporthouse.com>
Chris Wilson <chris@chris-wilson.co.uk> writes:
> Quoting Mika Kuoppala (2018-01-15 12:04:40)
>> Chris Wilson <chris@chris-wilson.co.uk> writes:
>>
>> > While we talk to the punit over its sideband, we need to prevent the cpu
>> > from sleeping in order to prevent a potential machine hang.
>> >
>> > Note that by itself, it appears that pm_qos_update_request (via
>> > intel_idle) doesn't provide a sufficient barrier to ensure that all core
>> > are indeed awake (out of Cstate) and that the package is awake. To do so,
>> > we need to supplement the pm_qos with a manual ping on_each_cpu.
>> >
>> > v2: Restrict the heavy-weight wakeup to just the ISOF_PORT_PUNIT, there
>> > is insufficient evidence to implicate a wider problem atm. Similarly,
>> > restrict the w/a to Valleyview, as Cherryview doesn't have an angry cadre
>> > of users.
>> >
>>
>> One datapoint about the v1 of this patch with the cpu ping in it.
>> The j1900 byt did end up with system hang during weekend with
>> drm-tip + v1.
>
> Not much different (supposedly in v2, especially if we ignore the bits
> after the revert), and v2 ran most of Fri-Mon without incident. (Most
> because I tested a few other things as well, such as eliminating the
> waitboosting for glxgears in the reproducer.)
>
> 1 hang in 100 hours across 2 machines. Certainly the best we've achieved
> so far (while allowing RPS to frequently adjust gpufreq). Any fresh ideas?
Since you asked, I tried to express one idea with a fresh patch:
20180116152116.17900-1-mika.kuoppala@linux.intel.com
-Mika
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-01-16 15:27 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-15 8:47 Vlv punit w/a (take two) Chris Wilson
2018-01-15 8:47 ` [PATCH v2 01/11] drm/i915: Disable preemption and sleeping while using the punit sideband Chris Wilson
2018-01-15 12:04 ` Mika Kuoppala
2018-01-15 12:13 ` Chris Wilson
2018-01-16 15:27 ` Mika Kuoppala [this message]
2018-01-15 12:21 ` Chris Wilson
2018-01-15 13:07 ` Hans de Goede
2018-01-15 13:43 ` Mika Kuoppala
2018-01-22 12:54 ` Chris Wilson
2018-01-15 8:47 ` [PATCH v2 02/11] drm/i915: Lift acquiring the vlv punit magic to a common sb-get Chris Wilson
2018-01-15 10:36 ` Mika Kuoppala
2018-01-15 8:47 ` [PATCH v2 03/11] drm/i915: Lift sideband locking for vlv_punit_(read|write) Chris Wilson
2018-01-15 8:47 ` [PATCH v2 04/11] drm/i915: Reduce RPS update frequency on Valleyview/Cherryview Chris Wilson
2018-01-15 8:47 ` [PATCH v2 05/11] Revert "drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3" Chris Wilson
2018-01-15 8:47 ` [PATCH v2 06/11] drm/i915: Replace pcu_lock with sb_lock Chris Wilson
2018-01-15 8:47 ` [PATCH v2 07/11] drm/i915: Separate sideband declarations to intel_sideband.h Chris Wilson
2018-01-15 8:47 ` [PATCH v2 08/11] drm/i915: Merge sbi read/write into a single accessor Chris Wilson
2018-01-15 8:47 ` [PATCH v2 09/11] drm/i915: Merge sandybride_pcode_(read|write) Chris Wilson
2018-01-15 8:47 ` [PATCH v2 10/11] drm/i915: Move sandybride pcode access to intel_sideband.c Chris Wilson
2018-01-19 8:21 ` Mika Kuoppala
2018-01-19 8:33 ` Chris Wilson
2018-01-15 8:47 ` [PATCH v2 11/11] drm/i915: Avoid waitboosting on the active request Chris Wilson
2018-01-18 9:49 ` Joonas Lahtinen
2018-01-15 9:19 ` ✓ Fi.CI.BAT: success for series starting with [v2,01/11] drm/i915: Disable preemption and sleeping while using the punit sideband Patchwork
2018-01-15 10:23 ` ✗ Fi.CI.IGT: failure " Patchwork
2018-01-15 10:27 ` Chris Wilson
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=87tvvlj029.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=hdegoede@redhat.com \
--cc=intel-gfx@lists.freedesktop.org \
/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 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.