* Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
@ 2016-10-12 12:06 ` Paul Bolle
0 siblings, 0 replies; 18+ messages in thread
From: Paul Bolle @ 2016-10-12 12:06 UTC (permalink / raw)
To: Joonas Lahtinen, Daniel Vetter, Jani Nikula, David Airlie
Cc: intel-gfx, linux-kernel, dri-devel
On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
> Bisecting the offending commit between v4.8 and v4.8.1 would be a good
> start.
That would be between v4.7 and v4.8. (I guess my report was ambiguous.)
That might take some time. Because bisecting always takes a long time
and especially since hitting this WARNING sometimes takes over an hour.
Anyhow, please prod me if I stay silent for too long.
Thanks,
Paul Bolle
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
2016-10-12 12:06 ` [Intel-gfx] " Paul Bolle
@ 2016-10-12 14:34 ` Jani Nikula
-1 siblings, 0 replies; 18+ messages in thread
From: Jani Nikula @ 2016-10-12 14:34 UTC (permalink / raw)
To: Paul Bolle, Joonas Lahtinen, Daniel Vetter, David Airlie
Cc: intel-gfx, linux-kernel, dri-devel
On Wed, 12 Oct 2016, Paul Bolle <pebolle@tiscali.nl> wrote:
> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
>> Bisecting the offending commit between v4.8 and v4.8.1 would be a good
>> start.
>
> That would be between v4.7 and v4.8. (I guess my report was ambiguous.)
>
> That might take some time. Because bisecting always takes a long time
> and especially since hitting this WARNING sometimes takes over an hour.
> Anyhow, please prod me if I stay silent for too long.
In the mean time, please file a bug over at [1] so we don't lose track.
BR,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
@ 2016-10-12 14:34 ` Jani Nikula
0 siblings, 0 replies; 18+ messages in thread
From: Jani Nikula @ 2016-10-12 14:34 UTC (permalink / raw)
To: Paul Bolle, Joonas Lahtinen, Daniel Vetter, David Airlie
Cc: intel-gfx, linux-kernel, dri-devel
On Wed, 12 Oct 2016, Paul Bolle <pebolle@tiscali.nl> wrote:
> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
>> Bisecting the offending commit between v4.8 and v4.8.1 would be a good
>> start.
>
> That would be between v4.7 and v4.8. (I guess my report was ambiguous.)
>
> That might take some time. Because bisecting always takes a long time
> and especially since hitting this WARNING sometimes takes over an hour.
> Anyhow, please prod me if I stay silent for too long.
In the mean time, please file a bug over at [1] so we don't lose track.
BR,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
2016-10-12 14:34 ` Jani Nikula
@ 2016-10-12 14:47 ` Paul Bolle
-1 siblings, 0 replies; 18+ messages in thread
From: Paul Bolle @ 2016-10-12 14:47 UTC (permalink / raw)
To: Jani Nikula, Joonas Lahtinen, Daniel Vetter, David Airlie
Cc: intel-gfx, linux-kernel, dri-devel
On Wed, 2016-10-12 at 17:34 +0300, Jani Nikula wrote:
> In the mean time, please file a bug over at [1] so we don't lose
> track.
Done: https://bugs.freedesktop.org/show_bug.cgi?id=98214
Paul Bolle
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
2016-10-12 12:06 ` [Intel-gfx] " Paul Bolle
@ 2016-10-12 18:48 ` Paul Bolle
-1 siblings, 0 replies; 18+ messages in thread
From: Paul Bolle @ 2016-10-12 18:48 UTC (permalink / raw)
To: Joonas Lahtinen, Daniel Vetter, Jani Nikula, David Airlie
Cc: intel-gfx, linux-kernel, dri-devel
On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
> That might take some time. Because bisecting always takes a long time
> and especially since hitting this WARNING sometimes takes over an hour.
> Anyhow, please prod me if I stay silent for too long.
For the record: I just had to power cycle this laptop because it got
into that lovely state where it just locks without accepting any input
(no, I don't have netconsole enabled).
Assuming this lockup is related: this could be more urgent than I
thought.
Paul Bolle
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
@ 2016-10-12 18:48 ` Paul Bolle
0 siblings, 0 replies; 18+ messages in thread
From: Paul Bolle @ 2016-10-12 18:48 UTC (permalink / raw)
To: Joonas Lahtinen, Daniel Vetter, Jani Nikula, David Airlie
Cc: intel-gfx, linux-kernel, dri-devel
On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
> That might take some time. Because bisecting always takes a long time
> and especially since hitting this WARNING sometimes takes over an hour.
> Anyhow, please prod me if I stay silent for too long.
For the record: I just had to power cycle this laptop because it got
into that lovely state where it just locks without accepting any input
(no, I don't have netconsole enabled).
Assuming this lockup is related: this could be more urgent than I
thought.
Paul Bolle
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
2016-10-12 12:06 ` [Intel-gfx] " Paul Bolle
@ 2016-10-24 20:47 ` Paul Bolle
-1 siblings, 0 replies; 18+ messages in thread
From: Paul Bolle @ 2016-10-24 20:47 UTC (permalink / raw)
To: Joonas Lahtinen, Daniel Vetter, Jani Nikula, David Airlie
Cc: intel-gfx, linux-kernel, dri-devel
[Detailed post, but please give it a quick scan.]
On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
> > Bisecting the offending commit between v4.8 and v4.8.1 would be a good
> > start.
>
> That would be between v4.7 and v4.8. (I guess my report was
> ambiguous.)
>
> That might take some time. Because bisecting always takes a long time
> and especially since hitting this WARNING sometimes takes over an hour.
> Anyhow, please prod me if I stay silent for too long.
0) So I've lost my courage to do a bisect when my first attempt landed
me in v4.6-rc3. This is about for issue popping up between v4.7 and
v4.8-rc1.
1) So I used the most reliable debugging tool that I actually
understand: printk():
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index fbcfed63a76e..791de414cf1e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14771,10 +14771,16 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct intel_crtc_state *crtc_state
return DRM_PLANE_HELPER_NO_SCALING;
crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
- cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
+ if (WARN_ON_ONCE(!crtc_clock))
+ return DRM_PLANE_HELPER_NO_SCALING;
- if (WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock))
+ cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
+ if (WARN_ON_ONCE(cdclk < crtc_clock)) {
+ printk(KERN_DEBUG "i915: cdclk < crtc_clock: %d < %d\n", cdclk, crtc_clock);
return DRM_PLANE_HELPER_NO_SCALING;
+ }
+
+ printk_ratelimited(KERN_DEBUG "i915: cdclk >= crtc_clock: %d >= %d\n", cdclk, crtc_clock);
/*
* skl max scale is lower of:
2) This taught me that crtc_clock always is 373250 on my machine. cdclk
mostly is 450000, but every now and then it briefly is 337500.
3) Now the interesting pattern is that cdclk drops to 337500 only after
two quick calls of skl_max_scale() with cdclk set to 450000, and a
roughly 300ms pause before the third call of that function. Example:
<7>[23758.501933] i915: cdclk >= crtc_clock: 450000 >= 373250
<7>[23758.515211] i915: cdclk >= crtc_clock: 450000 >= 373250
<7>[23758.869057] i915: cdclk < crtc_clock: 337500 < 373250
This pattern of cdclk being 337500 after roughly 300ms is surprisingly
stable.
4) So _perhaps_ there's some roughly 300ms timeout, somehow, somewhere,
that sets cdclk to 337500 and triggers this issue. Ideas?
To be continued,
Paul Bolle
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
@ 2016-10-24 20:47 ` Paul Bolle
0 siblings, 0 replies; 18+ messages in thread
From: Paul Bolle @ 2016-10-24 20:47 UTC (permalink / raw)
To: Joonas Lahtinen, Daniel Vetter, Jani Nikula, David Airlie
Cc: intel-gfx, linux-kernel, dri-devel
[Detailed post, but please give it a quick scan.]
On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
> > Bisecting the offending commit between v4.8 and v4.8.1 would be a good
> > start.
>
> That would be between v4.7 and v4.8. (I guess my report was
> ambiguous.)
>
> That might take some time. Because bisecting always takes a long time
> and especially since hitting this WARNING sometimes takes over an hour.
> Anyhow, please prod me if I stay silent for too long.
0) So I've lost my courage to do a bisect when my first attempt landed
me in v4.6-rc3. This is about for issue popping up between v4.7 and
v4.8-rc1.
1) So I used the most reliable debugging tool that I actually
understand: printk():
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index fbcfed63a76e..791de414cf1e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14771,10 +14771,16 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct intel_crtc_state *crtc_state
return DRM_PLANE_HELPER_NO_SCALING;
crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
- cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
+ if (WARN_ON_ONCE(!crtc_clock))
+ return DRM_PLANE_HELPER_NO_SCALING;
- if (WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock))
+ cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
+ if (WARN_ON_ONCE(cdclk < crtc_clock)) {
+ printk(KERN_DEBUG "i915: cdclk < crtc_clock: %d < %d\n", cdclk, crtc_clock);
return DRM_PLANE_HELPER_NO_SCALING;
+ }
+
+ printk_ratelimited(KERN_DEBUG "i915: cdclk >= crtc_clock: %d >= %d\n", cdclk, crtc_clock);
/*
* skl max scale is lower of:
2) This taught me that crtc_clock always is 373250 on my machine. cdclk
mostly is 450000, but every now and then it briefly is 337500.
3) Now the interesting pattern is that cdclk drops to 337500 only after
two quick calls of skl_max_scale() with cdclk set to 450000, and a
roughly 300ms pause before the third call of that function. Example:
<7>[23758.501933] i915: cdclk >= crtc_clock: 450000 >= 373250
<7>[23758.515211] i915: cdclk >= crtc_clock: 450000 >= 373250
<7>[23758.869057] i915: cdclk < crtc_clock: 337500 < 373250
This pattern of cdclk being 337500 after roughly 300ms is surprisingly
stable.
4) So _perhaps_ there's some roughly 300ms timeout, somehow, somewhere,
that sets cdclk to 337500 and triggers this issue. Ideas?
To be continued,
Paul Bolle
^ permalink raw reply related [flat|nested] 18+ messages in thread* Re: drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
2016-10-24 20:47 ` [Intel-gfx] " Paul Bolle
@ 2016-10-25 8:37 ` Jani Nikula
-1 siblings, 0 replies; 18+ messages in thread
From: Jani Nikula @ 2016-10-25 8:37 UTC (permalink / raw)
To: Paul Bolle, Joonas Lahtinen, Daniel Vetter, David Airlie
Cc: intel-gfx, linux-kernel, dri-devel
On Mon, 24 Oct 2016, Paul Bolle <pebolle@tiscali.nl> wrote:
> [Detailed post, but please give it a quick scan.]
Please file the information in the bug you filed. Please attach dmesg
(again, on the bug) with drm.debug=14 and running your patch.
BR,
Jani.
>
> On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
>> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
>> > Bisecting the offending commit between v4.8 and v4.8.1 would be a good
>> > start.
>>
>> That would be between v4.7 and v4.8. (I guess my report was
>> ambiguous.)
>>
>> That might take some time. Because bisecting always takes a long time
>> and especially since hitting this WARNING sometimes takes over an hour.
>> Anyhow, please prod me if I stay silent for too long.
>
> 0) So I've lost my courage to do a bisect when my first attempt landed
> me in v4.6-rc3. This is about for issue popping up between v4.7 and
> v4.8-rc1.
>
> 1) So I used the most reliable debugging tool that I actually
> understand: printk():
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index fbcfed63a76e..791de414cf1e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14771,10 +14771,16 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct intel_crtc_state *crtc_state
> return DRM_PLANE_HELPER_NO_SCALING;
>
> crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
> - cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
> + if (WARN_ON_ONCE(!crtc_clock))
> + return DRM_PLANE_HELPER_NO_SCALING;
>
> - if (WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock))
> + cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
> + if (WARN_ON_ONCE(cdclk < crtc_clock)) {
> + printk(KERN_DEBUG "i915: cdclk < crtc_clock: %d < %d\n", cdclk, crtc_clock);
> return DRM_PLANE_HELPER_NO_SCALING;
> + }
> +
> + printk_ratelimited(KERN_DEBUG "i915: cdclk >= crtc_clock: %d >= %d\n", cdclk, crtc_clock);
>
> /*
> * skl max scale is lower of:
>
> 2) This taught me that crtc_clock always is 373250 on my machine. cdclk
> mostly is 450000, but every now and then it briefly is 337500.
>
> 3) Now the interesting pattern is that cdclk drops to 337500 only after
> two quick calls of skl_max_scale() with cdclk set to 450000, and a
> roughly 300ms pause before the third call of that function. Example:
>
> <7>[23758.501933] i915: cdclk >= crtc_clock: 450000 >= 373250
> <7>[23758.515211] i915: cdclk >= crtc_clock: 450000 >= 373250
> <7>[23758.869057] i915: cdclk < crtc_clock: 337500 < 373250
>
> This pattern of cdclk being 337500 after roughly 300ms is surprisingly
> stable.
>
> 4) So _perhaps_ there's some roughly 300ms timeout, somehow, somewhere,
> that sets cdclk to 337500 and triggers this issue. Ideas?
>
> To be continued,
>
>
> Paul Bolle
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
@ 2016-10-25 8:37 ` Jani Nikula
0 siblings, 0 replies; 18+ messages in thread
From: Jani Nikula @ 2016-10-25 8:37 UTC (permalink / raw)
To: Paul Bolle, Joonas Lahtinen, Daniel Vetter, David Airlie
Cc: intel-gfx, linux-kernel, dri-devel
On Mon, 24 Oct 2016, Paul Bolle <pebolle@tiscali.nl> wrote:
> [Detailed post, but please give it a quick scan.]
Please file the information in the bug you filed. Please attach dmesg
(again, on the bug) with drm.debug=14 and running your patch.
BR,
Jani.
>
> On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
>> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
>> > Bisecting the offending commit between v4.8 and v4.8.1 would be a good
>> > start.
>>
>> That would be between v4.7 and v4.8. (I guess my report was
>> ambiguous.)
>>
>> That might take some time. Because bisecting always takes a long time
>> and especially since hitting this WARNING sometimes takes over an hour.
>> Anyhow, please prod me if I stay silent for too long.
>
> 0) So I've lost my courage to do a bisect when my first attempt landed
> me in v4.6-rc3. This is about for issue popping up between v4.7 and
> v4.8-rc1.
>
> 1) So I used the most reliable debugging tool that I actually
> understand: printk():
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index fbcfed63a76e..791de414cf1e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14771,10 +14771,16 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct intel_crtc_state *crtc_state
> return DRM_PLANE_HELPER_NO_SCALING;
>
> crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
> - cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
> + if (WARN_ON_ONCE(!crtc_clock))
> + return DRM_PLANE_HELPER_NO_SCALING;
>
> - if (WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock))
> + cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
> + if (WARN_ON_ONCE(cdclk < crtc_clock)) {
> + printk(KERN_DEBUG "i915: cdclk < crtc_clock: %d < %d\n", cdclk, crtc_clock);
> return DRM_PLANE_HELPER_NO_SCALING;
> + }
> +
> + printk_ratelimited(KERN_DEBUG "i915: cdclk >= crtc_clock: %d >= %d\n", cdclk, crtc_clock);
>
> /*
> * skl max scale is lower of:
>
> 2) This taught me that crtc_clock always is 373250 on my machine. cdclk
> mostly is 450000, but every now and then it briefly is 337500.
>
> 3) Now the interesting pattern is that cdclk drops to 337500 only after
> two quick calls of skl_max_scale() with cdclk set to 450000, and a
> roughly 300ms pause before the third call of that function. Example:
>
> <7>[23758.501933] i915: cdclk >= crtc_clock: 450000 >= 373250
> <7>[23758.515211] i915: cdclk >= crtc_clock: 450000 >= 373250
> <7>[23758.869057] i915: cdclk < crtc_clock: 337500 < 373250
>
> This pattern of cdclk being 337500 after roughly 300ms is surprisingly
> stable.
>
> 4) So _perhaps_ there's some roughly 300ms timeout, somehow, somewhere,
> that sets cdclk to 337500 and triggers this issue. Ideas?
>
> To be continued,
>
>
> Paul Bolle
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply [flat|nested] 18+ messages in thread