* [PATCH] drm/i915/display: Reduce log level for DP command signal timeout
@ 2019-03-14 17:58 Vanshidhar Konda
2019-03-14 18:31 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
` (4 more replies)
0 siblings, 5 replies; 13+ messages in thread
From: Vanshidhar Konda @ 2019-03-14 17:58 UTC (permalink / raw)
To: intel-gfx
The log level for timeout after waiting for a signal on the DP aux
channel control register is set to DRM_ERROR. But this is timeout not a
fatal error as the driver is expected to retry the command. Failure
after all retries is already captured as an error. Hence, reducing the
log for a timeout to warning instead of error.
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 47857f96c3b1..f51e8b2ccb17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
if (!done)
- DRM_ERROR("dp aux hw did not signal timeout!\n");
+ DRM_WARN("dp aux hw did not signal timeout!\n");
#undef C
return status;
--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 13+ messages in thread
* ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Reduce log level for DP command signal timeout
2019-03-14 17:58 [PATCH] drm/i915/display: Reduce log level for DP command signal timeout Vanshidhar Konda
@ 2019-03-14 18:31 ` Patchwork
2019-03-14 18:37 ` [PATCH] " Vanshidhar Konda
` (3 subsequent siblings)
4 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2019-03-14 18:31 UTC (permalink / raw)
To: Vanshidhar Konda; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/display: Reduce log level for DP command signal timeout
URL : https://patchwork.freedesktop.org/series/58012/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
293506d0bd92 drm/i915/display: Reduce log level for DP command signal timeout
-:25: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s)
total: 1 errors, 0 warnings, 0 checks, 8 lines checked
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] drm/i915/display: Reduce log level for DP command signal timeout
2019-03-14 17:58 [PATCH] drm/i915/display: Reduce log level for DP command signal timeout Vanshidhar Konda
2019-03-14 18:31 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
@ 2019-03-14 18:37 ` Vanshidhar Konda
2019-03-14 18:39 ` Ville Syrjälä
` (2 subsequent siblings)
4 siblings, 0 replies; 13+ messages in thread
From: Vanshidhar Konda @ 2019-03-14 18:37 UTC (permalink / raw)
To: intel-gfx; +Cc: Dixit
I'll add the Signed Off by line when I re-submit the patch after a
review.
Thanks,
Vanshi
On Thu, Mar 14, 2019 at 10:58:49AM -0700, Vanshidhar Konda wrote:
>The log level for timeout after waiting for a signal on the DP aux
>channel control register is set to DRM_ERROR. But this is timeout not a
>fatal error as the driver is expected to retry the command. Failure
>after all retries is already captured as an error. Hence, reducing the
>log for a timeout to warning instead of error.
>---
>drivers/gpu/drm/i915/intel_dp.c | 2 +-
>1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>index 47857f96c3b1..f51e8b2ccb17 100644
>--- a/drivers/gpu/drm/i915/intel_dp.c
>+++ b/drivers/gpu/drm/i915/intel_dp.c
>@@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
>
> if (!done)
>- DRM_ERROR("dp aux hw did not signal timeout!\n");
>+ DRM_WARN("dp aux hw did not signal timeout!\n");
>#undef C
>
> return status;
>--
>2.20.1
>
>_______________________________________________
>Intel-gfx mailing list
>Intel-gfx@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] drm/i915/display: Reduce log level for DP command signal timeout
2019-03-14 17:58 [PATCH] drm/i915/display: Reduce log level for DP command signal timeout Vanshidhar Konda
2019-03-14 18:31 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2019-03-14 18:37 ` [PATCH] " Vanshidhar Konda
@ 2019-03-14 18:39 ` Ville Syrjälä
2019-03-14 20:26 ` Vanshidhar Konda
2019-03-14 19:08 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-03-15 4:01 ` ✗ Fi.CI.IGT: failure " Patchwork
4 siblings, 1 reply; 13+ messages in thread
From: Ville Syrjälä @ 2019-03-14 18:39 UTC (permalink / raw)
To: Vanshidhar Konda; +Cc: intel-gfx
On Thu, Mar 14, 2019 at 10:58:49AM -0700, Vanshidhar Konda wrote:
> The log level for timeout after waiting for a signal on the DP aux
> channel control register is set to DRM_ERROR. But this is timeout not a
> fatal error as the driver is expected to retry the command. Failure
> after all retries is already captured as an error. Hence, reducing the
> log for a timeout to warning instead of error.
> ---
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 47857f96c3b1..f51e8b2ccb17 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
>
> if (!done)
> - DRM_ERROR("dp aux hw did not signal timeout!\n");
> + DRM_WARN("dp aux hw did not signal timeout!\n");
IIRC this indicates the hw is broken.
> #undef C
>
> return status;
> --
> 2.20.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* ✓ Fi.CI.BAT: success for drm/i915/display: Reduce log level for DP command signal timeout
2019-03-14 17:58 [PATCH] drm/i915/display: Reduce log level for DP command signal timeout Vanshidhar Konda
` (2 preceding siblings ...)
2019-03-14 18:39 ` Ville Syrjälä
@ 2019-03-14 19:08 ` Patchwork
2019-03-15 4:01 ` ✗ Fi.CI.IGT: failure " Patchwork
4 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2019-03-14 19:08 UTC (permalink / raw)
To: Vanshidhar Konda; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/display: Reduce log level for DP command signal timeout
URL : https://patchwork.freedesktop.org/series/58012/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5747 -> Patchwork_12464
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://patchwork.freedesktop.org/api/1.0/series/58012/revisions/1/mbox/
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_12464:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live_objects:
- {fi-icl-y}: PASS -> TIMEOUT
Known issues
------------
Here are the changes found in Patchwork_12464 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_cs_nop@nop-compute0:
- fi-ilk-650: NOTRUN -> SKIP [fdo#109271] +69
* igt@amdgpu/amd_cs_nop@sync-compute0:
- fi-bdw-gvtdvm: NOTRUN -> SKIP [fdo#109271] +42
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-icl-u3: NOTRUN -> SKIP [fdo#109315] +17
* igt@gem_ctx_create@basic-files:
- fi-gdg-551: NOTRUN -> SKIP [fdo#109271] +106
* igt@gem_exec_basic@gtt-bsd1:
- fi-icl-u3: NOTRUN -> SKIP [fdo#109276] +7
* igt@gem_exec_basic@gtt-bsd2:
- fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] +57
* igt@gem_exec_basic@readonly-bsd2:
- fi-pnv-d510: NOTRUN -> SKIP [fdo#109271] +76
* igt@gem_exec_parse@basic-rejected:
- fi-icl-u3: NOTRUN -> SKIP [fdo#109289] +1
* igt@gem_exec_store@basic-bsd2:
- fi-hsw-4770: NOTRUN -> SKIP [fdo#109271] +41
* igt@i915_selftest@live_contexts:
- fi-icl-u3: NOTRUN -> DMESG-FAIL [fdo#108569]
* igt@kms_addfb_basic@addfb25-y-tiled-small:
- fi-byt-n2820: NOTRUN -> SKIP [fdo#109271] +56
* igt@kms_busy@basic-flip-c:
- fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-byt-clapper: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-gdg-551: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-pnv-d510: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-ilk-650: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
- fi-byt-n2820: NOTRUN -> SKIP [fdo#109271] / [fdo#109278]
* igt@kms_chamelium@hdmi-crc-fast:
- fi-byt-j1900: NOTRUN -> SKIP [fdo#109271] +52
* igt@kms_chamelium@hdmi-edid-read:
- fi-hsw-peppy: NOTRUN -> SKIP [fdo#109271] +46
- fi-icl-u3: NOTRUN -> SKIP [fdo#109284] +8
* igt@kms_force_connector_basic@force-load-detect:
- fi-bxt-j4205: NOTRUN -> SKIP [fdo#109271] +47
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-icl-u3: NOTRUN -> SKIP [fdo#109285] +3
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: NOTRUN -> DMESG-FAIL [fdo#102614] / [fdo#107814]
- fi-byt-clapper: NOTRUN -> FAIL [fdo#103167]
* igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
- fi-byt-clapper: NOTRUN -> FAIL [fdo#103191] / [fdo#107362] +1
* igt@kms_psr@primary_page_flip:
- fi-apl-guc: NOTRUN -> SKIP [fdo#109271] +50
* igt@runner@aborted:
- fi-bxt-dsi: NOTRUN -> FAIL [fdo#109516]
#### Possible fixes ####
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@gem_flink_basic@flink-lifetime:
- {fi-icl-y}: DMESG-WARN [fdo#109638] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107814]: https://bugs.freedesktop.org/show_bug.cgi?id=107814
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109516]: https://bugs.freedesktop.org/show_bug.cgi?id=109516
[fdo#109638]: https://bugs.freedesktop.org/show_bug.cgi?id=109638
[fdo#109673]: https://bugs.freedesktop.org/show_bug.cgi?id=109673
[fdo#109779]: https://bugs.freedesktop.org/show_bug.cgi?id=109779
Participating hosts (32 -> 41)
------------------------------
Additional (13): fi-bxt-dsi fi-byt-j1900 fi-hsw-peppy fi-bdw-gvtdvm fi-apl-guc fi-ilk-650 fi-hsw-4770 fi-bxt-j4205 fi-gdg-551 fi-icl-u3 fi-pnv-d510 fi-byt-n2820 fi-byt-clapper
Missing (4): fi-hsw-4770r fi-ilk-m540 fi-bsw-cyan fi-bdw-samus
Build changes
-------------
* Linux: CI_DRM_5747 -> Patchwork_12464
CI_DRM_5747: 5b9f7d954ed4502fddc9d4b0ee09e59a1ef92895 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4885: 1e057f43cd30ab6acfd40794673843942521c0c5 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12464: 293506d0bd9271a3753c250d775f6e7d9903d132 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
293506d0bd92 drm/i915/display: Reduce log level for DP command signal timeout
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12464/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] drm/i915/display: Reduce log level for DP command signal timeout
2019-03-14 18:39 ` Ville Syrjälä
@ 2019-03-14 20:26 ` Vanshidhar Konda
2019-03-14 20:47 ` Ville Syrjälä
0 siblings, 1 reply; 13+ messages in thread
From: Vanshidhar Konda @ 2019-03-14 20:26 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
On Thu, Mar 14, 2019 at 08:39:11PM +0200, Ville Syrjälä wrote:
>On Thu, Mar 14, 2019 at 10:58:49AM -0700, Vanshidhar Konda wrote:
>> The log level for timeout after waiting for a signal on the DP aux
>> channel control register is set to DRM_ERROR. But this is timeout not a
>> fatal error as the driver is expected to retry the command. Failure
>> after all retries is already captured as an error. Hence, reducing the
>> log for a timeout to warning instead of error.
>> ---
>> drivers/gpu/drm/i915/intel_dp.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index 47857f96c3b1..f51e8b2ccb17 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
>> trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
>>
>> if (!done)
>> - DRM_ERROR("dp aux hw did not signal timeout!\n");
>> + DRM_WARN("dp aux hw did not signal timeout!\n");
>
>IIRC this indicates the hw is broken.
>
Does this indicate an issue with Intel GFX/display device, or the
display/monitor connected to the DP port?
FYI, this is for FDO #109982
(https://bugzilla.freedesktop.org/show_bug.cgi?id=109982).
From the logs, it seems like this timeout only occurs once. The next try
succeeds without issues.
>> #undef C
>>
>> return status;
>> --
>> 2.20.1
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>--
>Ville Syrjälä
>Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] drm/i915/display: Reduce log level for DP command signal timeout
2019-03-14 20:26 ` Vanshidhar Konda
@ 2019-03-14 20:47 ` Ville Syrjälä
2019-03-14 21:00 ` Vanshidhar Konda
0 siblings, 1 reply; 13+ messages in thread
From: Ville Syrjälä @ 2019-03-14 20:47 UTC (permalink / raw)
To: Vanshidhar Konda; +Cc: intel-gfx
On Thu, Mar 14, 2019 at 01:26:00PM -0700, Vanshidhar Konda wrote:
> On Thu, Mar 14, 2019 at 08:39:11PM +0200, Ville Syrjälä wrote:
> >On Thu, Mar 14, 2019 at 10:58:49AM -0700, Vanshidhar Konda wrote:
> >> The log level for timeout after waiting for a signal on the DP aux
> >> channel control register is set to DRM_ERROR. But this is timeout not a
> >> fatal error as the driver is expected to retry the command. Failure
> >> after all retries is already captured as an error. Hence, reducing the
> >> log for a timeout to warning instead of error.
> >> ---
> >> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> >> index 47857f96c3b1..f51e8b2ccb17 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> >> trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
> >>
> >> if (!done)
> >> - DRM_ERROR("dp aux hw did not signal timeout!\n");
> >> + DRM_WARN("dp aux hw did not signal timeout!\n");
> >
> >IIRC this indicates the hw is broken.
> >
> Does this indicate an issue with Intel GFX/display device, or the
> display/monitor connected to the DP port?
>
> FYI, this is for FDO #109982
> (https://bugzilla.freedesktop.org/show_bug.cgi?id=109982).
There's nothing connected I believe. But in either case I believe
the aux hw should terminate with a proper timeout. I'm tempted to
blame the typec/tbt stuff here too.
>
> >From the logs, it seems like this timeout only occurs once. The next try
> succeeds without issues.
>
> >> #undef C
> >>
> >> return status;
> >> --
> >> 2.20.1
> >>
> >> _______________________________________________
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >--
> >Ville Syrjälä
> >Intel
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] drm/i915/display: Reduce log level for DP command signal timeout
2019-03-14 20:47 ` Ville Syrjälä
@ 2019-03-14 21:00 ` Vanshidhar Konda
2019-03-14 21:09 ` Ville Syrjälä
0 siblings, 1 reply; 13+ messages in thread
From: Vanshidhar Konda @ 2019-03-14 21:00 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
On Thu, Mar 14, 2019 at 10:47:56PM +0200, Ville Syrjälä wrote:
>On Thu, Mar 14, 2019 at 01:26:00PM -0700, Vanshidhar Konda wrote:
>> On Thu, Mar 14, 2019 at 08:39:11PM +0200, Ville Syrjälä wrote:
>> >On Thu, Mar 14, 2019 at 10:58:49AM -0700, Vanshidhar Konda wrote:
>> >> The log level for timeout after waiting for a signal on the DP aux
>> >> channel control register is set to DRM_ERROR. But this is timeout not a
>> >> fatal error as the driver is expected to retry the command. Failure
>> >> after all retries is already captured as an error. Hence, reducing the
>> >> log for a timeout to warning instead of error.
>> >> ---
>> >> drivers/gpu/drm/i915/intel_dp.c | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> >> index 47857f96c3b1..f51e8b2ccb17 100644
>> >> --- a/drivers/gpu/drm/i915/intel_dp.c
>> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> >> @@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
>> >> trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
>> >>
>> >> if (!done)
>> >> - DRM_ERROR("dp aux hw did not signal timeout!\n");
>> >> + DRM_WARN("dp aux hw did not signal timeout!\n");
>> >
>> >IIRC this indicates the hw is broken.
>> >
>> Does this indicate an issue with Intel GFX/display device, or the
>> display/monitor connected to the DP port?
>>
>> FYI, this is for FDO #109982
>> (https://bugzilla.freedesktop.org/show_bug.cgi?id=109982).
>
>There's nothing connected I believe. But in either case I believe
From the two logs for the issue, e-DP1 is the only display connected to
the test machine when it generated this error.
>the aux hw should terminate with a proper timeout. I'm tempted to
If we think that there should be no timeout, would it make more sense to
return an error to the caller and having the caller handle the error?
>blame the typec/tbt stuff here too.
>
>>
>> >From the logs, it seems like this timeout only occurs once. The next try
>> succeeds without issues.
>>
>> >> #undef C
>> >>
>> >> return status;
>> >> --
>> >> 2.20.1
>> >>
>> >> _______________________________________________
>> >> Intel-gfx mailing list
>> >> Intel-gfx@lists.freedesktop.org
>> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> >
>> >--
>> >Ville Syrjälä
>> >Intel
>
>--
>Ville Syrjälä
>Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] drm/i915/display: Reduce log level for DP command signal timeout
2019-03-14 21:00 ` Vanshidhar Konda
@ 2019-03-14 21:09 ` Ville Syrjälä
2019-03-15 1:37 ` Vanshidhar Konda
0 siblings, 1 reply; 13+ messages in thread
From: Ville Syrjälä @ 2019-03-14 21:09 UTC (permalink / raw)
To: Vanshidhar Konda; +Cc: intel-gfx
On Thu, Mar 14, 2019 at 02:00:29PM -0700, Vanshidhar Konda wrote:
> On Thu, Mar 14, 2019 at 10:47:56PM +0200, Ville Syrjälä wrote:
> >On Thu, Mar 14, 2019 at 01:26:00PM -0700, Vanshidhar Konda wrote:
> >> On Thu, Mar 14, 2019 at 08:39:11PM +0200, Ville Syrjälä wrote:
> >> >On Thu, Mar 14, 2019 at 10:58:49AM -0700, Vanshidhar Konda wrote:
> >> >> The log level for timeout after waiting for a signal on the DP aux
> >> >> channel control register is set to DRM_ERROR. But this is timeout not a
> >> >> fatal error as the driver is expected to retry the command. Failure
> >> >> after all retries is already captured as an error. Hence, reducing the
> >> >> log for a timeout to warning instead of error.
> >> >> ---
> >> >> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> >> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> >> >> index 47857f96c3b1..f51e8b2ccb17 100644
> >> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> >> @@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> >> >> trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
> >> >>
> >> >> if (!done)
> >> >> - DRM_ERROR("dp aux hw did not signal timeout!\n");
> >> >> + DRM_WARN("dp aux hw did not signal timeout!\n");
> >> >
> >> >IIRC this indicates the hw is broken.
> >> >
> >> Does this indicate an issue with Intel GFX/display device, or the
> >> display/monitor connected to the DP port?
> >>
> >> FYI, this is for FDO #109982
> >> (https://bugzilla.freedesktop.org/show_bug.cgi?id=109982).
> >
> >There's nothing connected I believe. But in either case I believe
>
> >From the two logs for the issue, e-DP1 is the only display connected to
> the test machine when it generated this error.
>
> >the aux hw should terminate with a proper timeout. I'm tempted to
>
> If we think that there should be no timeout, would it make more sense to
> return an error to the caller and having the caller handle the error?
How would it handle the error?
>
> >blame the typec/tbt stuff here too.
> >
> >>
> >> >From the logs, it seems like this timeout only occurs once. The next try
> >> succeeds without issues.
> >>
> >> >> #undef C
> >> >>
> >> >> return status;
> >> >> --
> >> >> 2.20.1
> >> >>
> >> >> _______________________________________________
> >> >> Intel-gfx mailing list
> >> >> Intel-gfx@lists.freedesktop.org
> >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >> >
> >> >--
> >> >Ville Syrjälä
> >> >Intel
> >
> >--
> >Ville Syrjälä
> >Intel
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] drm/i915/display: Reduce log level for DP command signal timeout
2019-03-14 21:09 ` Ville Syrjälä
@ 2019-03-15 1:37 ` Vanshidhar Konda
2019-03-15 13:35 ` Ville Syrjälä
0 siblings, 1 reply; 13+ messages in thread
From: Vanshidhar Konda @ 2019-03-15 1:37 UTC (permalink / raw)
To: Ville Syrjälä, lucas.demarchi; +Cc: intel-gfx
On Thu, Mar 14, 2019 at 11:09:38PM +0200, Ville Syrjälä wrote:
>On Thu, Mar 14, 2019 at 02:00:29PM -0700, Vanshidhar Konda wrote:
>> On Thu, Mar 14, 2019 at 10:47:56PM +0200, Ville Syrjälä wrote:
>> >On Thu, Mar 14, 2019 at 01:26:00PM -0700, Vanshidhar Konda wrote:
>> >> On Thu, Mar 14, 2019 at 08:39:11PM +0200, Ville Syrjälä wrote:
>> >> >On Thu, Mar 14, 2019 at 10:58:49AM -0700, Vanshidhar Konda wrote:
>> >> >> The log level for timeout after waiting for a signal on the DP aux
>> >> >> channel control register is set to DRM_ERROR. But this is timeout not a
>> >> >> fatal error as the driver is expected to retry the command. Failure
>> >> >> after all retries is already captured as an error. Hence, reducing the
>> >> >> log for a timeout to warning instead of error.
>> >> >> ---
>> >> >> drivers/gpu/drm/i915/intel_dp.c | 2 +-
>> >> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >>
>> >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> >> >> index 47857f96c3b1..f51e8b2ccb17 100644
>> >> >> --- a/drivers/gpu/drm/i915/intel_dp.c
>> >> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> >> >> @@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
>> >> >> trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
>> >> >>
>> >> >> if (!done)
>> >> >> - DRM_ERROR("dp aux hw did not signal timeout!\n");
>> >> >> + DRM_WARN("dp aux hw did not signal timeout!\n");
>> >> >
>> >> >IIRC this indicates the hw is broken.
>> >> >
>> >> Does this indicate an issue with Intel GFX/display device, or the
>> >> display/monitor connected to the DP port?
>> >>
>> >> FYI, this is for FDO #109982
>> >> (https://bugzilla.freedesktop.org/show_bug.cgi?id=109982).
>> >
>> >There's nothing connected I believe. But in either case I believe
>>
>> >From the two logs for the issue, e-DP1 is the only display connected to
>> the test machine when it generated this error.
>>
>> >the aux hw should terminate with a proper timeout. I'm tempted to
>>
>> If we think that there should be no timeout, would it make more sense to
>> return an error to the caller and having the caller handle the error?
>
>How would it handle the error?
>
>>
>> >blame the typec/tbt stuff here too.
Could it be possible that the addition of typec/tbt to ICL has added
additional latency to the DP register being signaled? Would it make
sense to increase the 10 ms timeout to something larger?
>> >
>> >>
>> >> >From the logs, it seems like this timeout only occurs once. The next try
>> >> succeeds without issues.
>> >>
>> >> >> #undef C
>> >> >>
>> >> >> return status;
>> >> >> --
>> >> >> 2.20.1
>> >> >>
>> >> >> _______________________________________________
>> >> >> Intel-gfx mailing list
>> >> >> Intel-gfx@lists.freedesktop.org
>> >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> >> >
>> >> >--
>> >> >Ville Syrjälä
>> >> >Intel
>> >
>> >--
>> >Ville Syrjälä
>> >Intel
>
>--
>Ville Syrjälä
>Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* ✗ Fi.CI.IGT: failure for drm/i915/display: Reduce log level for DP command signal timeout
2019-03-14 17:58 [PATCH] drm/i915/display: Reduce log level for DP command signal timeout Vanshidhar Konda
` (3 preceding siblings ...)
2019-03-14 19:08 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2019-03-15 4:01 ` Patchwork
4 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2019-03-15 4:01 UTC (permalink / raw)
To: Vanshidhar Konda; +Cc: intel-gfx
== Series Details ==
Series: drm/i915/display: Reduce log level for DP command signal timeout
URL : https://patchwork.freedesktop.org/series/58012/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5747_full -> Patchwork_12464_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_12464_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12464_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_12464_full:
### IGT changes ###
#### Possible regressions ####
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-c:
- shard-iclb: NOTRUN -> INCOMPLETE
#### Warnings ####
* igt@gem_ppgtt@blt-vs-render-ctx0:
- shard-iclb: INCOMPLETE [fdo#109100] / [fdo#109766] / [fdo#109801] -> DMESG-WARN
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_plane@pixel-format-pipe-b-planes}:
- shard-skl: NOTRUN -> FAIL
Known issues
------------
Here are the changes found in Patchwork_12464_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_caching@read-writes:
- shard-iclb: PASS -> TIMEOUT [fdo#109673] +2
* igt@gem_ctx_isolation@bcs0-s3:
- shard-iclb: NOTRUN -> FAIL [fdo#103375]
* igt@gem_exec_capture@capture-bsd2:
- shard-snb: NOTRUN -> SKIP [fdo#109271] +116
* igt@gem_exec_parse@chained-batch:
- shard-iclb: NOTRUN -> SKIP [fdo#109289] +3
* igt@gem_mocs_settings@mocs-reset-ctx-render:
- shard-iclb: NOTRUN -> SKIP [fdo#109287] +3
* igt@gem_mocs_settings@mocs-settings-bsd1:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] / [fdo#109287]
* igt@gem_stolen@stolen-pwrite:
- shard-iclb: NOTRUN -> SKIP [fdo#109277] +1
* igt@i915_pm_rpm@cursor:
- shard-skl: NOTRUN -> INCOMPLETE [fdo#107807]
* igt@i915_selftest@live_workarounds:
- shard-iclb: PASS -> DMESG-FAIL [fdo#108954]
* igt@kms_atomic_transition@4x-modeset-transitions:
- shard-snb: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +12
* igt@kms_busy@extended-modeset-hang-newfb-render-b:
- shard-iclb: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-glk: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +3
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-e:
- shard-iclb: NOTRUN -> SKIP [fdo#109278] +3
* igt@kms_ccs@pipe-b-crc-sprite-planes-basic:
- shard-iclb: PASS -> FAIL [fdo#107725]
* igt@kms_chamelium@dp-hpd-storm-disable:
- shard-iclb: NOTRUN -> SKIP [fdo#109284] +1
* igt@kms_chv_cursor_fail@pipe-c-128x128-top-edge:
- shard-skl: PASS -> FAIL [fdo#104671]
* igt@kms_color@pipe-b-legacy-gamma:
- shard-iclb: NOTRUN -> FAIL [fdo#104782] +1
* igt@kms_cursor_crc@cursor-128x128-dpms:
- shard-skl: NOTRUN -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-128x128-suspend:
- shard-skl: PASS -> INCOMPLETE [fdo#104108]
* igt@kms_cursor_crc@cursor-256x256-suspend:
- shard-skl: NOTRUN -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_cursor_crc@cursor-256x85-random:
- shard-apl: PASS -> FAIL [fdo#103232] +1
* igt@kms_cursor_crc@cursor-512x512-offscreen:
- shard-iclb: NOTRUN -> SKIP [fdo#109279]
* igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic:
- shard-iclb: NOTRUN -> SKIP [fdo#109274] +6
* igt@kms_flip@2x-flip-vs-panning-vs-hang-interruptible:
- shard-glk: PASS -> INCOMPLETE [fdo#103359] / [k.org#198133]
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: PASS -> FAIL [fdo#105363]
* igt@kms_flip_tiling@flip-y-tiled:
- shard-skl: PASS -> FAIL [fdo#108303]
* igt@kms_force_connector_basic@force-connector-state:
- shard-iclb: NOTRUN -> SKIP [fdo#109285]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-apl: PASS -> FAIL [fdo#103167] +1
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
- shard-glk: PASS -> FAIL [fdo#103167] +4
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-render:
- shard-iclb: PASS -> FAIL [fdo#103167] +8
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-blt:
- shard-iclb: NOTRUN -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-mmap-wc:
- shard-iclb: PASS -> FAIL [fdo#105682] / [fdo#109247]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-blt:
- shard-skl: NOTRUN -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-shrfb-draw-mmap-gtt:
- shard-iclb: PASS -> FAIL [fdo#109247] +13
* igt@kms_frontbuffer_tracking@psr-2p-scndscrn-spr-indfb-draw-mmap-gtt:
- shard-iclb: NOTRUN -> SKIP [fdo#109280] +20
* igt@kms_frontbuffer_tracking@psr-rgb101010-draw-mmap-gtt:
- shard-iclb: NOTRUN -> FAIL [fdo#109247] +4
* igt@kms_panel_fitting@legacy:
- shard-skl: NOTRUN -> FAIL [fdo#105456]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-e:
- shard-skl: NOTRUN -> SKIP [fdo#109271] / [fdo#109278] +10
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c:
- shard-skl: NOTRUN -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
- shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
- shard-skl: PASS -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: NOTRUN -> FAIL [fdo#107815]
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: NOTRUN -> FAIL [fdo#108145] +1
* igt@kms_psr@primary_page_flip:
- shard-iclb: PASS -> FAIL [fdo#107383] +3
* igt@kms_psr@psr2_cursor_plane_onoff:
- shard-iclb: NOTRUN -> SKIP [fdo#109441] +1
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: PASS -> SKIP [fdo#109441] +2
* igt@kms_psr@sprite_mmap_cpu:
- shard-iclb: NOTRUN -> FAIL [fdo#107383]
* igt@kms_psr@suspend:
- shard-skl: PASS -> INCOMPLETE [fdo#107773]
* igt@kms_rotation_crc@primary-rotation-180:
- shard-skl: NOTRUN -> FAIL [fdo#103925] / [fdo#107815]
* igt@kms_vblank@pipe-a-query-forked:
- shard-kbl: PASS -> DMESG-WARN [fdo#103558] / [fdo#105602] +16
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-hsw: PASS -> FAIL [fdo#104894]
* igt@perf_pmu@busy-accuracy-50-vcs1:
- shard-skl: NOTRUN -> SKIP [fdo#109271] +116
* igt@perf_pmu@busy-no-semaphores-vcs1:
- shard-iclb: NOTRUN -> SKIP [fdo#109276] +5
* igt@prime_nv_pcopy@test2:
- shard-iclb: NOTRUN -> SKIP [fdo#109291] +2
#### Possible fixes ####
* igt@gem_create@create-clear:
- shard-iclb: INCOMPLETE [fdo#109100] -> PASS
* igt@gem_partial_pwrite_pread@write-display:
- shard-iclb: TIMEOUT [fdo#109673] -> PASS +1
* igt@kms_atomic_transition@1x-modeset-transitions-fencing:
- shard-skl: FAIL [fdo#108470] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-render-c:
- shard-skl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_color@pipe-a-ctm-max:
- shard-apl: FAIL [fdo#108147] -> PASS
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS +1
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: FAIL [fdo#103191] / [fdo#103232] -> PASS
* igt@kms_cursor_legacy@cursor-vs-flip-legacy:
- shard-iclb: FAIL [fdo#103355] -> PASS +1
* igt@kms_flip@2x-modeset-vs-vblank-race:
- shard-glk: FAIL [fdo#103060] -> PASS
* igt@kms_flip@flip-vs-suspend:
- shard-kbl: DMESG-WARN [fdo#108566] -> PASS
- shard-skl: INCOMPLETE [fdo#109507] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-render:
- shard-glk: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-onoff:
- shard-apl: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-pwrite:
- shard-skl: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-pwrite:
- shard-iclb: FAIL [fdo#103167] -> PASS +7
* igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-render:
- shard-iclb: FAIL [fdo#105682] / [fdo#109247] -> PASS
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-cur-indfb-draw-pwrite:
- shard-iclb: FAIL [fdo#109247] -> PASS +10
* igt@kms_frontbuffer_tracking@psr-suspend:
- shard-skl: INCOMPLETE [fdo#104108] / [fdo#106978] -> PASS
* {igt@kms_plane@plane-position-covered-pipe-a-planes}:
- shard-apl: FAIL [fdo#110038] -> PASS
* {igt@kms_plane@plane-position-covered-pipe-b-planes}:
- shard-glk: FAIL [fdo#110038] -> PASS
* {igt@kms_plane_multiple@atomic-pipe-c-tiling-none}:
- shard-glk: FAIL [fdo#110037] -> PASS +1
* {igt@kms_plane_multiple@atomic-pipe-c-tiling-yf}:
- shard-iclb: FAIL [fdo#110037] -> PASS
* igt@kms_psr2_su@frontbuffer:
- shard-iclb: SKIP [fdo#109642] -> PASS
* igt@kms_psr@psr2_suspend:
- shard-iclb: SKIP [fdo#109441] -> PASS +2
* igt@kms_psr@sprite_blt:
- shard-iclb: FAIL [fdo#107383] -> PASS +2
* igt@kms_rotation_crc@multiplane-rotation-cropping-bottom:
- shard-kbl: DMESG-FAIL [fdo#105763] -> PASS
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl: FAIL [fdo#109016] -> PASS
* igt@kms_setmode@basic:
- shard-hsw: FAIL [fdo#99912] -> PASS
* {igt@kms_universal_plane@universal-plane-pipe-a-functional}:
- shard-apl: FAIL [fdo#110037] -> PASS
* igt@syncobj_wait@invalid-signal-bad-pad:
- shard-kbl: DMESG-WARN [fdo#103558] / [fdo#105602] -> PASS
#### Warnings ####
* igt@gem_ppgtt@blt-vs-render-ctxn:
- shard-iclb: INCOMPLETE [fdo#107713] / [fdo#109766] / [fdo#109801] -> DMESG-FAIL [fdo#109766] / [fdo#109801]
* igt@kms_plane_scaling@pipe-a-scaler-with-pixel-format:
- shard-glk: SKIP [fdo#109271] / [fdo#109278] -> FAIL [fdo#110098] +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103355]: https://bugs.freedesktop.org/show_bug.cgi?id=103355
[fdo#103359]: https://bugs.freedesktop.org/show_bug.cgi?id=103359
[fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#103925]: https://bugs.freedesktop.org/show_bug.cgi?id=103925
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#104671]: https://bugs.freedesktop.org/show_bug.cgi?id=104671
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#104894]: https://bugs.freedesktop.org/show_bug.cgi?id=104894
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#105456]: https://bugs.freedesktop.org/show_bug.cgi?id=105456
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#105682]: https://bugs.freedesktop.org/show_bug.cgi?id=105682
[fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
[fdo#106978]: https://bugs.freedesktop.org/show_bug.cgi?id=106978
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107383]: https://bugs.freedesktop.org/show_bug.cgi?id=107383
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107725]: https://bugs.freedesktop.org/show_bug.cgi?id=107725
[fdo#107773]: https://bugs.freedesktop.org/show_bug.cgi?id=107773
[fdo#107807]: https://bugs.freedesktop.org/show_bug.cgi?id=107807
[fdo#107815]: https://bugs.freedesktop.org/show_bug.cgi?id=107815
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#108303]: https://bugs.freedesktop.org/show_bug.cgi?id=108303
[fdo#108470]: https://bugs.freedesktop.org/show_bug.cgi?id=108470
[fdo#108566]: https://bugs.freedesktop.org/show_bug.cgi?id=108566
[fdo#108954]: https://bugs.freedesktop.org/show_bug.cgi?id=108954
[fdo#109016]: https://bugs.freedesktop.org/show_bug.cgi?id=109016
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#109247]: https://bugs.freedesktop.org/show_bug.cgi?id=109247
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109277]: https://bugs.freedesktop.org/show_bug.cgi?id=109277
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109279]: https://bugs.freedesktop.org/show_bug.cgi?id=109279
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109287]: https://bugs.freedesktop.org/show_bug.cgi?id=109287
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109291]: https://bugs.freedesktop.org/show_bug.cgi?id=109291
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#109507]: https://bugs.freedesktop.org/show_bug.cgi?id=109507
[fdo#109642]: https://bugs.freedesktop.org/show_bug.cgi?id=109642
[fdo#109673]: https://bugs.freedesktop.org/show_bug.cgi?id=109673
[fdo#109766]: https://bugs.freedesktop.org/show_bug.cgi?id=109766
[fdo#109801]: https://bugs.freedesktop.org/show_bug.cgi?id=109801
[fdo#110037]: https://bugs.freedesktop.org/show_bug.cgi?id=110037
[fdo#110038]: https://bugs.freedesktop.org/show_bug.cgi?id=110038
[fdo#110098]: https://bugs.freedesktop.org/show_bug.cgi?id=110098
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
[k.org#198133]: https://bugzilla.kernel.org/show_bug.cgi?id=198133
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* Linux: CI_DRM_5747 -> Patchwork_12464
CI_DRM_5747: 5b9f7d954ed4502fddc9d4b0ee09e59a1ef92895 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_4885: 1e057f43cd30ab6acfd40794673843942521c0c5 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12464: 293506d0bd9271a3753c250d775f6e7d9903d132 @ 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_12464/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] drm/i915/display: Reduce log level for DP command signal timeout
2019-03-15 1:37 ` Vanshidhar Konda
@ 2019-03-15 13:35 ` Ville Syrjälä
2019-03-15 15:59 ` Vanshidhar Konda
0 siblings, 1 reply; 13+ messages in thread
From: Ville Syrjälä @ 2019-03-15 13:35 UTC (permalink / raw)
To: Vanshidhar Konda; +Cc: intel-gfx, lucas.demarchi
On Thu, Mar 14, 2019 at 06:37:22PM -0700, Vanshidhar Konda wrote:
> On Thu, Mar 14, 2019 at 11:09:38PM +0200, Ville Syrjälä wrote:
> >On Thu, Mar 14, 2019 at 02:00:29PM -0700, Vanshidhar Konda wrote:
> >> On Thu, Mar 14, 2019 at 10:47:56PM +0200, Ville Syrjälä wrote:
> >> >On Thu, Mar 14, 2019 at 01:26:00PM -0700, Vanshidhar Konda wrote:
> >> >> On Thu, Mar 14, 2019 at 08:39:11PM +0200, Ville Syrjälä wrote:
> >> >> >On Thu, Mar 14, 2019 at 10:58:49AM -0700, Vanshidhar Konda wrote:
> >> >> >> The log level for timeout after waiting for a signal on the DP aux
> >> >> >> channel control register is set to DRM_ERROR. But this is timeout not a
> >> >> >> fatal error as the driver is expected to retry the command. Failure
> >> >> >> after all retries is already captured as an error. Hence, reducing the
> >> >> >> log for a timeout to warning instead of error.
> >> >> >> ---
> >> >> >> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> >> >> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >> >> >>
> >> >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> >> >> >> index 47857f96c3b1..f51e8b2ccb17 100644
> >> >> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> >> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> >> >> @@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
> >> >> >> trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
> >> >> >>
> >> >> >> if (!done)
> >> >> >> - DRM_ERROR("dp aux hw did not signal timeout!\n");
> >> >> >> + DRM_WARN("dp aux hw did not signal timeout!\n");
> >> >> >
> >> >> >IIRC this indicates the hw is broken.
> >> >> >
> >> >> Does this indicate an issue with Intel GFX/display device, or the
> >> >> display/monitor connected to the DP port?
> >> >>
> >> >> FYI, this is for FDO #109982
> >> >> (https://bugzilla.freedesktop.org/show_bug.cgi?id=109982).
> >> >
> >> >There's nothing connected I believe. But in either case I believe
> >>
> >> >From the two logs for the issue, e-DP1 is the only display connected to
> >> the test machine when it generated this error.
> >>
> >> >the aux hw should terminate with a proper timeout. I'm tempted to
> >>
> >> If we think that there should be no timeout, would it make more sense to
> >> return an error to the caller and having the caller handle the error?
> >
> >How would it handle the error?
> >
> >>
> >> >blame the typec/tbt stuff here too.
> Could it be possible that the addition of typec/tbt to ICL has added
> additional latency to the DP register being signaled? Would it make
> sense to increase the 10 ms timeout to something larger?
Imre just told me the hw timeout was increased to 4ms. So 10ms should
still be sufficient I guess. But it wouldn't hurt to at least test
longer timeouts a bit to see if the hw ever gets around to signalling
the timeout.
>
> >> >
> >> >>
> >> >> >From the logs, it seems like this timeout only occurs once. The next try
> >> >> succeeds without issues.
> >> >>
> >> >> >> #undef C
> >> >> >>
> >> >> >> return status;
> >> >> >> --
> >> >> >> 2.20.1
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Intel-gfx mailing list
> >> >> >> Intel-gfx@lists.freedesktop.org
> >> >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >> >> >
> >> >> >--
> >> >> >Ville Syrjälä
> >> >> >Intel
> >> >
> >> >--
> >> >Ville Syrjälä
> >> >Intel
> >
> >--
> >Ville Syrjälä
> >Intel
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] drm/i915/display: Reduce log level for DP command signal timeout
2019-03-15 13:35 ` Ville Syrjälä
@ 2019-03-15 15:59 ` Vanshidhar Konda
0 siblings, 0 replies; 13+ messages in thread
From: Vanshidhar Konda @ 2019-03-15 15:59 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx, lucas.demarchi
On Fri, Mar 15, 2019 at 03:35:04PM +0200, Ville Syrjälä wrote:
>On Thu, Mar 14, 2019 at 06:37:22PM -0700, Vanshidhar Konda wrote:
>> On Thu, Mar 14, 2019 at 11:09:38PM +0200, Ville Syrjälä wrote:
>> >On Thu, Mar 14, 2019 at 02:00:29PM -0700, Vanshidhar Konda wrote:
>> >> On Thu, Mar 14, 2019 at 10:47:56PM +0200, Ville Syrjälä wrote:
>> >> >On Thu, Mar 14, 2019 at 01:26:00PM -0700, Vanshidhar Konda wrote:
>> >> >> On Thu, Mar 14, 2019 at 08:39:11PM +0200, Ville Syrjälä wrote:
>> >> >> >On Thu, Mar 14, 2019 at 10:58:49AM -0700, Vanshidhar Konda wrote:
>> >> >> >> The log level for timeout after waiting for a signal on the DP aux
>> >> >> >> channel control register is set to DRM_ERROR. But this is timeout not a
>> >> >> >> fatal error as the driver is expected to retry the command. Failure
>> >> >> >> after all retries is already captured as an error. Hence, reducing the
>> >> >> >> log for a timeout to warning instead of error.
>> >> >> >> ---
>> >> >> >> drivers/gpu/drm/i915/intel_dp.c | 2 +-
>> >> >> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >> >> >>
>> >> >> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> >> >> >> index 47857f96c3b1..f51e8b2ccb17 100644
>> >> >> >> --- a/drivers/gpu/drm/i915/intel_dp.c
>> >> >> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> >> >> >> @@ -1069,7 +1069,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp)
>> >> >> >> trace_i915_reg_rw(false, ch_ctl, status, sizeof(status), true);
>> >> >> >>
>> >> >> >> if (!done)
>> >> >> >> - DRM_ERROR("dp aux hw did not signal timeout!\n");
>> >> >> >> + DRM_WARN("dp aux hw did not signal timeout!\n");
>> >> >> >
>> >> >> >IIRC this indicates the hw is broken.
>> >> >> >
>> >> >> Does this indicate an issue with Intel GFX/display device, or the
>> >> >> display/monitor connected to the DP port?
>> >> >>
>> >> >> FYI, this is for FDO #109982
>> >> >> (https://bugzilla.freedesktop.org/show_bug.cgi?id=109982).
>> >> >
>> >> >There's nothing connected I believe. But in either case I believe
>> >>
>> >> >From the two logs for the issue, e-DP1 is the only display connected to
>> >> the test machine when it generated this error.
>> >>
>> >> >the aux hw should terminate with a proper timeout. I'm tempted to
>> >>
>> >> If we think that there should be no timeout, would it make more sense to
>> >> return an error to the caller and having the caller handle the error?
>> >
>> >How would it handle the error?
>> >
>> >>
>> >> >blame the typec/tbt stuff here too.
>> Could it be possible that the addition of typec/tbt to ICL has added
>> additional latency to the DP register being signaled? Would it make
>> sense to increase the 10 ms timeout to something larger?
>
>Imre just told me the hw timeout was increased to 4ms. So 10ms should
>still be sufficient I guess. But it wouldn't hurt to at least test
>longer timeouts a bit to see if the hw ever gets around to signalling
>the timeout.
>
Ok. Let me send a patch for that then. I'll cc you and Imre on that
patch. Thank you!
>>
>> >> >
>> >> >>
>> >> >> >From the logs, it seems like this timeout only occurs once. The next try
>> >> >> succeeds without issues.
>> >> >>
>> >> >> >> #undef C
>> >> >> >>
>> >> >> >> return status;
>> >> >> >> --
>> >> >> >> 2.20.1
>> >> >> >>
>> >> >> >> _______________________________________________
>> >> >> >> Intel-gfx mailing list
>> >> >> >> Intel-gfx@lists.freedesktop.org
>> >> >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> >> >> >
>> >> >> >--
>> >> >> >Ville Syrjälä
>> >> >> >Intel
>> >> >
>> >> >--
>> >> >Ville Syrjälä
>> >> >Intel
>> >
>> >--
>> >Ville Syrjälä
>> >Intel
>
>--
>Ville Syrjälä
>Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-03-15 15:59 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-14 17:58 [PATCH] drm/i915/display: Reduce log level for DP command signal timeout Vanshidhar Konda
2019-03-14 18:31 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2019-03-14 18:37 ` [PATCH] " Vanshidhar Konda
2019-03-14 18:39 ` Ville Syrjälä
2019-03-14 20:26 ` Vanshidhar Konda
2019-03-14 20:47 ` Ville Syrjälä
2019-03-14 21:00 ` Vanshidhar Konda
2019-03-14 21:09 ` Ville Syrjälä
2019-03-15 1:37 ` Vanshidhar Konda
2019-03-15 13:35 ` Ville Syrjälä
2019-03-15 15:59 ` Vanshidhar Konda
2019-03-14 19:08 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-03-15 4:01 ` ✗ Fi.CI.IGT: failure " 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.