On 22/03/16 10:07, Chris Wilson wrote:
On Tue, Mar 22, 2016 at 09:53:25AM +0000, Tvrtko Ursulin wrote:
On 21/03/16 11:22, Patchwork wrote:
== Series Details ==
Series: drm/i915: Name the anonymous per-engine context struct (rev2)
URL : https://patchwork.freedesktop.org/series/4635/
State : warning
== Summary ==
Series 4635v2 drm/i915: Name the anonymous per-engine context struct
http://patchwork.freedesktop.org/api/1.0/series/4635/revisions/2/mbox/
Test gem_ringfill:
Subgroup basic-default-s3:
dmesg-warn -> PASS (bsw-nuc-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE
Sporadic ILK pipe underruns:
https://bugs.freedesktop.org/show_bug.cgi?id=93787
Subgroup basic-flip-vs-wf_vblank:
fail -> PASS (byt-nuc)
Subgroup basic-plain-flip:
pass -> DMESG-WARN (hsw-brixbox)
Unrelated intermittent device suspended while HW access:
https://bugs.freedesktop.org/show_bug.cgi?id=94349
Test kms_force_connector_basic:
Subgroup force-connector-state:
pass -> SKIP (ilk-hp8440p)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-a:
dmesg-warn -> PASS (snb-x220t)
Subgroup nonblocking-crc-pipe-a-frame-sequence:
pass -> DMESG-WARN (snb-dellxps)
Same.
Subgroup suspend-read-crc-pipe-c:
pass -> DMESG-WARN (bsw-nuc-2)
Unrelated lockdep splat: https://bugs.freedesktop.org/show_bug.cgi?id=94350
Is it really the same one? There should be another lockdep chain that
isn't in bugzilla...
Looks the same to me:
Bz:
[ 179.762863] rtcwake/5995 is trying to acquire lock:
[ 179.762877] (s_active#6){++++.+}, at: [<ffffffff8124ec70>]
kernfs_remove_by_name_ns+0x40/0xa0
[ 179.762878]
but task is already holding lock:
[ 179.762885] (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81078c4d>]
cpu_hotplug_begin+0x6d/0xc0
[ 179.762886]
which lock already depends on the new lock.
This CI run:
[ 127.210522] rtcwake/5947 is trying to acquire lock:
[ 127.210539] (s_active#6){++++.+}, at: [<ffffffff81250740>]
kernfs_remove_by_name_ns+0x40/0xa0
[ 127.210540]
but task is already holding lock:
[ 127.210549] (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81078f5d>]
cpu_hotplug_begin+0x6d/0xc0
[ 127.210550]
which lock already depends on the new lock.
incomplete -> PASS (hsw-gt2)
Test pm_rpm:
Subgroup basic-pci-d3-state:
fail -> DMESG-FAIL (snb-x220t)
Device suspended while HW access again.
dmesg-warn -> PASS (snb-dellxps)
bdw-nuci7 total:194 pass:182 dwarn:0 dfail:0 fail:0 skip:12
bdw-ultra total:194 pass:173 dwarn:0 dfail:0 fail:0 skip:21
bsw-nuc-2 total:194 pass:156 dwarn:1 dfail:0 fail:0 skip:37
byt-nuc total:194 pass:159 dwarn:0 dfail:0 fail:0 skip:35
hsw-brixbox total:194 pass:171 dwarn:1 dfail:0 fail:0 skip:22
hsw-gt2 total:194 pass:176 dwarn:1 dfail:0 fail:0 skip:17
ilk-hp8440p total:194 pass:129 dwarn:1 dfail:0 fail:0 skip:64
ivb-t430s total:194 pass:169 dwarn:0 dfail:0 fail:0 skip:25
skl-i7k-2 total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23
snb-dellxps total:194 pass:159 dwarn:1 dfail:0 fail:0 skip:34
snb-x220t total:194 pass:160 dwarn:0 dfail:1 fail:0 skip:33
Results at /archive/results/CI_IGT_test/Patchwork_1649/
e7a7673e9840fe8b50a5a2894c75565ec7858a00 drm-intel-nightly: 2016y-03m-19d-10h-09m-53s UTC integration manifest
a1c5f9b1e8b9cbfdab0fb71ccf7a5a0838b56069 drm/i915: Name the anonymous per-engine context struct
So looking good.
Chris, r-b on v2? It was just a revert of a hunk which changed one
instance of ctx->i915->dev->struct_mutex to
engine->dev->struct_mutex which the CI reminded me is not allowed in
some places.
That one again! One day we will get engine init/fini sorted. Yes,
Yes r-b, just to be really sure?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
