drm/i915: Skip logging impossible slices
Subsystems (2)
Tvrtko Ursulin
maintainerPATCH 1/1 drm/i915: Skip logging impossible slices
From: Tvrtko Ursulin <[email protected]>
Log up to sseu->max_slices instead basing on ARRAY_SIZE since to avoid printing impossible and empty slices for a platform.
Also compact slice total and slice mask into one log line.
--- drivers/gpu/drm/i915/intel_device_info.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/gpu/drm/i915/intel_device_info.c +4 -4
@@ -83,11 +83,11 @@ static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) {int s; -drm_printf (p,"slice mask: %04x\n" , sseu->slice_mask); -drm_printf (p,"slice total: %u\n" ,hweight8 (sseu->slice_mask)); +drm_printf (p,"slice total: %u, mask=%04x\n" , +hweight8 (sseu->slice_mask), sseu->slice_mask);drm_printf (p,"subslice total: %u\n" ,sseu_subslice_total (sseu)); -for (s =0 ; s <ARRAY_SIZE (sseu->subslice_mask); s++) { -drm_printf (p,"slice%d %u subslices mask=%04x\n" , +for (s =0 ; s < sseu->max_slices; s++) { +drm_printf (p,"slice%d: %u subslices, mask=%04x\n" , s,hweight8 (sseu->subslice_mask[s]), sseu->subslice_mask[s]); }
Signature · 6 lines
2.14.1 _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Tvrtko Ursulin (2018-03-21 10:32:28)
Quoted 22 lines
From: Tvrtko Ursulin <[email protected]>
Log up to
sseu->max_slicesinstead basing onARRAY_SIZEsince to avoid printing impossible and empty slices for a platform.Also compact slice total and slice mask into one log line.
Signed-off-by Tvrtko Ursulin <[email protected]>Cc Lionel Landwerlin <[email protected]>--- drivers/gpu/drm/i915/intel_device_info.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/gpu/drm/i915/intel_device_info.c +0
-1@@ -83,11 +83,11 @@ static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) {int s; -drm_printf (p,"slice mask: %04x\n" , sseu->slice_mask);
drivers/gpu/drm/i915/intel_device_info.c static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) · line 92
Quoted 10 lines
drivers/gpu/drm/i915/intel_device_info.c +4
-3-drm_printf (p,"slice total: %u\n" ,hweight8 (sseu->slice_mask)); +drm_printf (p,"slice total: %u, mask=%04x\n" , +hweight8 (sseu->slice_mask), sseu->slice_mask);drm_printf (p,"subslice total: %u\n" ,sseu_subslice_total (sseu)); -for (s =0 ; s <ARRAY_SIZE (sseu->subslice_mask); s++) { -drm_printf (p,"slice%d %u subslices mask=%04x\n" , +for (s =0 ; s < sseu->max_slices; s++) { +drm_printf (p,"slice%d: %u subslices, mask=%04x\n" , s,hweight8 (sseu->subslice_mask[s]), sseu->subslice_mask[s]);
Just idly testing the waters...
In yaml, this would be
"<indent>- slice%d: { subslices: %u, mask: 0x%04x }\n"
How do we feel about that in our debug output? And gradually use that style by default? (I'm planning on converting the error state wholesale...)
-chris
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Chris Wilson (2018-03-21 10:41:37)
Quoted 36 lines
Quoting Tvrtko Ursulin (2018-03-21 10:32:28)
Quoted 22 lines
From: Tvrtko Ursulin <[email protected]>
Log up to
sseu->max_slicesinstead basing onARRAY_SIZEsince to avoid printing impossible and empty slices for a platform.Also compact slice total and slice mask into one log line.
Signed-off-by Tvrtko Ursulin <[email protected]>Cc Lionel Landwerlin <[email protected]>--- drivers/gpu/drm/i915/intel_device_info.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/gpu/drm/i915/intel_device_info.c +0
-1@@ -83,11 +83,11 @@ static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) {int s; -drm_printf (p,"slice mask: %04x\n" , sseu->slice_mask);drivers/gpu/drm/i915/intel_device_info.c static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) · line 92
Quoted 10 lines
drivers/gpu/drm/i915/intel_device_info.c +4
-3-drm_printf (p,"slice total: %u\n" ,hweight8 (sseu->slice_mask)); +drm_printf (p,"slice total: %u, mask=%04x\n" , +hweight8 (sseu->slice_mask), sseu->slice_mask);drm_printf (p,"subslice total: %u\n" ,sseu_subslice_total (sseu)); -for (s =0 ; s <ARRAY_SIZE (sseu->subslice_mask); s++) { -drm_printf (p,"slice%d %u subslices mask=%04x\n" , +for (s =0 ; s < sseu->max_slices; s++) { +drm_printf (p,"slice%d: %u subslices, mask=%04x\n" , s,hweight8 (sseu->subslice_mask[s]), sseu->subslice_mask[s]);Just idly testing the waters...
Quoted 2 lines
In yaml, this would be
"<indent>- slice%d: { subslices: %u, mask: 0x%04x }\n"
Or if we keep the node name the same for easier parsing:
"<indent>- slice: { id:%u, subslices:%u, mask:0x%04x }\n"-Chris
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Jani Nikula
maintainerQuoted 37 lines · Chris Wilson
Quoting Chris Wilson (2018-03-21 10:41:37)
Quoted 36 lines
Quoting Tvrtko Ursulin (2018-03-21 10:32:28)
Quoted 22 lines
From: Tvrtko Ursulin <[email protected]>
Log up to
sseu->max_slicesinstead basing onARRAY_SIZEsince to avoid printing impossible and empty slices for a platform.Also compact slice total and slice mask into one log line.
Signed-off-by Tvrtko Ursulin <[email protected]>Cc Lionel Landwerlin <[email protected]>--- drivers/gpu/drm/i915/intel_device_info.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/gpu/drm/i915/intel_device_info.c +0
-1@@ -83,11 +83,11 @@ static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) {int s; -drm_printf (p,"slice mask: %04x\n" , sseu->slice_mask);drivers/gpu/drm/i915/intel_device_info.c static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) · line 92
Quoted 10 lines
drivers/gpu/drm/i915/intel_device_info.c +4
-3-drm_printf (p,"slice total: %u\n" ,hweight8 (sseu->slice_mask)); +drm_printf (p,"slice total: %u, mask=%04x\n" , +hweight8 (sseu->slice_mask), sseu->slice_mask);drm_printf (p,"subslice total: %u\n" ,sseu_subslice_total (sseu)); -for (s =0 ; s <ARRAY_SIZE (sseu->subslice_mask); s++) { -drm_printf (p,"slice%d %u subslices mask=%04x\n" , +for (s =0 ; s < sseu->max_slices; s++) { +drm_printf (p,"slice%d: %u subslices, mask=%04x\n" , s,hweight8 (sseu->subslice_mask[s]), sseu->subslice_mask[s]);Just idly testing the waters...
Quoted 6 lines
Quoted 2 lines
In yaml, this would be
"<indent>- slice%d: { subslices: %u, mask: 0x%04x }\n"Or if we keep the node name the same for easier parsing:
"<indent>- slice: { id:%u, subslices:%u, mask:0x%04x }\n"
I'm not against doing this, especially for gpu dumps.
Wouldn't json be easier to generate and parse? Or do you prefer the slightly better human readability of yaml?
I think it would be pretty straighforward to write drm printer helpers for printing valid json without having to actually manually print the colons and braces etc. And the struct drm_printer could even have checks for ensuring you don't burp verbatim stuff to a printer that's supposed to be json.
Any considerations for the transition? Massive wholesale patch bomb conversion? Yikes.
BR,
Jani.
Signature · 5 lines
Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Jani Nikula (2018-03-21 11:47:06)
Quoted 42 lines · Chris Wilson
Quoted 40 lines
Quoting Chris Wilson (2018-03-21 10:41:37)
Quoted 38 lines
Quoting Tvrtko Ursulin (2018-03-21 10:32:28)
Quoted 22 lines
From: Tvrtko Ursulin <[email protected]>
Log up to
sseu->max_slicesinstead basing onARRAY_SIZEsince to avoid printing impossible and empty slices for a platform.Also compact slice total and slice mask into one log line.
Signed-off-by Tvrtko Ursulin <[email protected]>Cc Lionel Landwerlin <[email protected]>--- drivers/gpu/drm/i915/intel_device_info.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/gpu/drm/i915/intel_device_info.c +0
-1@@ -83,11 +83,11 @@ static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) {int s; -drm_printf (p,"slice mask: %04x\n" , sseu->slice_mask);drivers/gpu/drm/i915/intel_device_info.c static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) · line 92
Quoted 10 lines
drivers/gpu/drm/i915/intel_device_info.c +4
-3-drm_printf (p,"slice total: %u\n" ,hweight8 (sseu->slice_mask)); +drm_printf (p,"slice total: %u, mask=%04x\n" , +hweight8 (sseu->slice_mask), sseu->slice_mask);drm_printf (p,"subslice total: %u\n" ,sseu_subslice_total (sseu)); -for (s =0 ; s <ARRAY_SIZE (sseu->subslice_mask); s++) { -drm_printf (p,"slice%d %u subslices mask=%04x\n" , +for (s =0 ; s < sseu->max_slices; s++) { +drm_printf (p,"slice%d: %u subslices, mask=%04x\n" , s,hweight8 (sseu->subslice_mask[s]), sseu->subslice_mask[s]);Just idly testing the waters...
In yaml, this would be
"<indent>- slice%d: { subslices: %u, mask: 0x%04x }\n"
Quoted 8 lines
Quoted 3 lines
Or if we keep the node name the same for easier parsing:
"<indent>- slice: { id:%u, subslices:%u, mask:0x%04x }\n"I'm not against doing this, especially for gpu dumps.
Wouldn't json be easier to generate and parse? Or do you prefer the slightly better human readability of yaml?
I think for any of the debug output preferring to keep it as readable as possible is essential. libyaml isn't that hard to use, even for a beginner like myself.
Quoted 5 lines
I think it would be pretty straighforward to write drm printer helpers for printing valid json without having to actually manually print the colons and braces etc. And the struct
drm_printercould even have checks for ensuring you don't burp verbatim stuff to a printer that's supposed to be json.
About the biggest challenge is tracking indent; which drm_printer already does iirc. Still, I think we want to move this into lib/
Quoted 2 lines
Any considerations for the transition? Massive wholesale patch bomb conversion? Yikes.
I think it's only worth converting bits and pieces that we are trying to parse. So quite a few debugfs are candidates, and the error-state being a prime example as we want to make it more amenable and flexible for future post-mortem capture depending on what userspace needs. (I might even go as far as all future debugfs should come with a parser for igt.) -Chris
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Jani Nikula
maintainerQuoted 47 lines · Chris Wilson
Quoting Jani Nikula (2018-03-21 11:47:06)
Quoted 46 lines · Chris Wilson
Quoted 43 lines
Quoting Chris Wilson (2018-03-21 10:41:37)
Quoted 36 lines
Quoting Tvrtko Ursulin (2018-03-21 10:32:28)
Quoted 22 lines
From: Tvrtko Ursulin <[email protected]>
Log up to
sseu->max_slicesinstead basing onARRAY_SIZEsince to avoid printing impossible and empty slices for a platform.Also compact slice total and slice mask into one log line.
Signed-off-by Tvrtko Ursulin <[email protected]>Cc Lionel Landwerlin <[email protected]>--- drivers/gpu/drm/i915/intel_device_info.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/gpu/drm/i915/intel_device_info.c +0
-1@@ -83,11 +83,11 @@ static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) {int s; -drm_printf (p,"slice mask: %04x\n" , sseu->slice_mask);drivers/gpu/drm/i915/intel_device_info.c static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) · line 92
Quoted 10 lines
drivers/gpu/drm/i915/intel_device_info.c +4
-3-drm_printf (p,"slice total: %u\n" ,hweight8 (sseu->slice_mask)); +drm_printf (p,"slice total: %u, mask=%04x\n" , +hweight8 (sseu->slice_mask), sseu->slice_mask);drm_printf (p,"subslice total: %u\n" ,sseu_subslice_total (sseu)); -for (s =0 ; s <ARRAY_SIZE (sseu->subslice_mask); s++) { -drm_printf (p,"slice%d %u subslices mask=%04x\n" , +for (s =0 ; s < sseu->max_slices; s++) { +drm_printf (p,"slice%d: %u subslices, mask=%04x\n" , s,hweight8 (sseu->subslice_mask[s]), sseu->subslice_mask[s]);Just idly testing the waters...
Quoted 2 lines
In yaml, this would be
"<indent>- slice%d: { subslices: %u, mask: 0x%04x }\n"Or if we keep the node name the same for easier parsing:
"<indent>- slice: { id:%u, subslices:%u, mask:0x%04x }\n"
Quoted 8 lines
Quoted 4 lines
I'm not against doing this, especially for gpu dumps.
Wouldn't json be easier to generate and parse? Or do you prefer the slightly better human readability of yaml?
I think for any of the debug output preferring to keep it as readable as possible is essential. libyaml isn't that hard to use, even for a beginner like myself.
Fair enough; I'm only familiar with json, and that's my natural reason to lean towards it.
Quoted 8 lines
Quoted 5 lines
I think it would be pretty straighforward to write drm printer helpers for printing valid json without having to actually manually print the colons and braces etc. And the struct
drm_printercould even have checks for ensuring you don't burp verbatim stuff to a printer that's supposed to be json.About the biggest challenge is tracking indent; which
drm_printeralready does iirc. Still, I think we want to move this intolib/
I agree having this in lib is preferrable. But apparently that requires moving the whole abstracted drm_printer style printing there first, and then hoping to get yaml/json added on top. There's bound to be some friction there.
Quoted 8 lines
Quoted 2 lines
Any considerations for the transition? Massive wholesale patch bomb conversion? Yikes.
I think it's only worth converting bits and pieces that we are trying to parse. So quite a few debugfs are candidates, and the error-state being a prime example as we want to make it more amenable and flexible for future post-mortem capture depending on what userspace needs. (I might even go as far as all future debugfs should come with a parser for igt.)
Oh, I did mean mass conversion on a per-debugfs-file basis, i.e. error state in one go. But I guess there's no way around that, anything else is just pain spread over a longer period.
I'd definitely go as far as saying any debugfs file that's supposed to be in a serialized format should have a corresponding parser in igt, and written *before* merging the kernel change.
There's also some discipline required wrt backward/forward compatibility to actually reap the benefits of the format. Can't just change the contents nilly willy with that either. It's not a magic bullet.
BR,
Jani.
Signature · 5 lines
Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Joonas Lahtinen
maintainerQuoting Jani Nikula (2018-03-21 14:16:37)
Quoted 19 lines · Chris Wilson
Quoted 18 lines
Quoting Jani Nikula (2018-03-21 11:47:06)
Quoted 16 lines
Quoted 11 lines
Quoting Chris Wilson (2018-03-21 10:41:37)
Quoted 5 lines
Just idly testing the waters...
In yaml, this would be
"<indent>- slice%d: { subslices: %u, mask: 0x%04x }\n"Or if we keep the node name the same for easier parsing:
"<indent>- slice: { id:%u, subslices:%u, mask:0x%04x }\n"I'm not against doing this, especially for gpu dumps.
Wouldn't json be easier to generate and parse? Or do you prefer the slightly better human readability of yaml?
Quoted 6 lines
Quoted 3 lines
I think for any of the debug output preferring to keep it as readable as possible is essential. libyaml isn't that hard to use, even for a beginner like myself.
Fair enough; I'm only familiar with json, and that's my natural reason to lean towards it.
JSON gets irritating to look at by plain eye. So I would agree that YAML would serve better when developers are likely to scroll through the file contents manually, too.
Then some more random thoughts:
This discussion will of course bring closer the can of forms that when we've formalized the debugfs format, does somebody expect it to stay more stable than not?
Having a counterpart in IGT and making that always match kernel, would be the obvious way to keep things sane.
Regards, Joonas
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoting Joonas Lahtinen (2018-03-23 12:29:54)
Quoted 31 lines
Quoting Jani Nikula (2018-03-21 14:16:37)
Quoted 19 lines · Chris Wilson
Quoted 18 lines
Quoting Jani Nikula (2018-03-21 11:47:06)
Quoted 16 lines
Quoted 11 lines
Quoting Chris Wilson (2018-03-21 10:41:37)
Quoted 5 lines
Just idly testing the waters...
In yaml, this would be
"<indent>- slice%d: { subslices: %u, mask: 0x%04x }\n"Or if we keep the node name the same for easier parsing:
"<indent>- slice: { id:%u, subslices:%u, mask:0x%04x }\n"I'm not against doing this, especially for gpu dumps.
Wouldn't json be easier to generate and parse? Or do you prefer the slightly better human readability of yaml?
Quoted 6 lines
Quoted 3 lines
I think for any of the debug output preferring to keep it as readable as possible is essential. libyaml isn't that hard to use, even for a beginner like myself.
Fair enough; I'm only familiar with json, and that's my natural reason to lean towards it.
JSON gets irritating to look at by plain eye. So I would agree that YAML would serve better when developers are likely to scroll through the file contents manually, too.
Quoted 5 lines
Then some more random thoughts:
This discussion will of course bring closer the can of forms that when we've formalized the debugfs format, does somebody expect it to stay more stable than not?
The starting point is that we do want to transition to an easier-to-extend file format for sysfs (the idea of it being single-valued is long gone :) There having a stable interface is without question, so getting the transition right is the challenge and then maintaining the hierarchy such that it is backwards and forward compatible with new content.
Quoted 2 lines
Having a counterpart in IGT and making that always match kernel, would be the obvious way to keep things sane.
Imo, if we aren't parsing debugfs in igt, then they can be dead code eliminated. So I expect yamlification to snow ball once we've got the first few done and a good feel for how to design kernel/igt API to suite us. Then it's just a matter of throwing each debugfs through a yamllint :)
-Chris
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Quoted 23 lines · Tvrtko Ursulin
From: Tvrtko Ursulin <[email protected]>
Log up to
sseu->max_slicesinstead basing onARRAY_SIZEsince to avoid printing impossible and empty slices for a platform.Also compact slice total and slice mask into one log line.
Signed-off-by Tvrtko Ursulin <[email protected]>Cc Lionel Landwerlin <[email protected]>--- drivers/gpu/drm/i915/intel_device_info.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)drivers/gpu/drm/i915/intel_device_info.c +0
-2@@ -83,11 +83,11 @@ static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) {int s; -drm_printf (p,"slice mask: %04x\n" , sseu->slice_mask); -drm_printf (p,"slice total: %u\n" ,hweight8 (sseu->slice_mask));
drivers/gpu/drm/i915/intel_device_info.c static void sseu_dump(const struct sseu_dev_info *sseu, struct drm_printer *p) · line 93
Quoted 10 lines
drivers/gpu/drm/i915/intel_device_info.c +4
-2+drm_printf (p,"slice total: %u, mask=%04x\n" , +hweight8 (sseu->slice_mask), sseu->slice_mask);drm_printf (p,"subslice total: %u\n" ,sseu_subslice_total (sseu)); -for (s =0 ; s <ARRAY_SIZE (sseu->subslice_mask); s++) { -drm_printf (p,"slice%d %u subslices mask=%04x\n" , +for (s =0 ; s < sseu->max_slices; s++) { +drm_printf (p,"slice%d: %u subslices, mask=%04x\n" , s,hweight8 (sseu->subslice_mask[s]), sseu->subslice_mask[s]); }
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Patchwork
CI✓ Fi.CI.BAT: success for drm/i915: Skip logging impossible slices
In reply to Tvrtko Ursulin== Series Details ==
== Series Details ==
Series: drm/i915: Skip logging impossible slices
URL : https://patchwork.freedesktop.org/series/40367/
State : success
== Summary ==
Series 40367v1 drm/i915: Skip logging impossible slices
https://patchwork.freedesktop.org/api/1.0/series/40367/revisions/1/mbox/
---- Known issues:
Test gem_mmap_gtt:
Subgroup basic-small-bo-tiledx:
pass -> FAIL (fi-gdg-551) fdo#102575
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
incomplete -> PASS (fi-cfl-s2) fdo#105641
Test prime_vgem:
Subgroup basic-fence-flip:
pass -> FAIL (fi-ilk-650) fdo#104008fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575
fdo#105641 https://bugs.freedesktop.org/show_bug.cgi?id=105641
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:433s fi-bdw-gvtdvm total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:443s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:541s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:510s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:509s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:514s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:508s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:409s fi-cfl-s2 total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:580s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:523s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:413s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:314s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:402s fi-ilk-650 total:285 pass:224 dwarn:0 dfail:0 fail:1 skip:60 time:419s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:469s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:432s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:475s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:468s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:514s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:652s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:441s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:529s fi-skl-6700k2 total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:506s fi-skl-6770hq total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:506s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:429s fi-skl-gvtdvm total:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:586s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:399s
9d737cebc219c821989021a3115424165ff7b052 drm-tip: 2018y-03m-20d-14h-56m-05s UTC integration manifest 1787d01b7782 drm/i915: Skip logging impossible slices
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8429/issues.html
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Patchwork
CI✗ Fi.CI.IGT: warning for drm/i915: Skip logging impossible slices
In reply to Tvrtko Ursulin== Series Details ==
== Series Details ==
Series: drm/i915: Skip logging impossible slices
URL : https://patchwork.freedesktop.org/series/40367/
State : warning
== Summary ==
---- Possible new issues:
Test kms_setmode:
Subgroup clone-exclusive-crtc:
pass -> DMESG-WARN (shard-hsw)---- Known issues:
Test kms_vblank:
Subgroup pipe-b-ts-continuation-dpms-suspend:
incomplete -> PASS (shard-hsw) fdo#105054fdo#105054 https://bugs.freedesktop.org/show_bug.cgi?id=105054
shard-apl total:3478 pass:1815 dwarn:1 dfail:0 fail:6 skip:1655 time:13139s shard-hsw total:3478 pass:1767 dwarn:2 dfail:0 fail:1 skip:1707 time:11858s shard-snb total:3478 pass:1358 dwarn:1 dfail:0 fail:2 skip:2117 time:7304s
Blacklisted hosts:
shard-kbl total:3478 pass:1939 dwarn:1 dfail:0 fail:10 skip:1528 time:9952s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8429/shards.html
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx