Created attachment 83084 [details] dmesgofrunningprime_nv_api System Environment: -------------------------- Platform: Ivybridge Kernel: (drm-intel-nightly)353890ae582631254dd0920b707d3a320908242e Merge: 2f5bb91 bf903e4 Bug detailed description: ----------------------------- Running prime_nv_api shows: flink names don't match and Call Trace at dmesg: [ 107.183355] ------------[ cut here ]------------ [ 107.183404] WARNING: CPU: 6 PID: 4095 at drivers/gpu/drm/i915/i915_gem.c:3977 i915_gem_free_object+0xf3/0x19d [i915]() [ 107.183463] Modules linked in: ipv6 dm_mod snd_hda_codec_hdmi firewire_ohci firewire_core crc_itu_t iTCO_wdt iTCO_vendor_support snd_hda_codec_realtek pcspkr i2c_i801 lpc_ich mfd_core shpchp snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer i915 snd soundcore acpi_cpufreq nouveau mxm_wmi wmi ttm video button drm_kms_helper drm mperf freq_table [ 107.183747] CPU: 6 PID: 4095 Comm: prime_nv_api Not tainted 3.11.0-rc2_nightlytop_353890_debug_20130727_+ #6261 [ 107.183803] Hardware name: Intel Corporation 2012 Client Platform/LosLunas 2 CRB, BIOS ACRVMBY1.86C.0067.B00.1110301023 10/30/2011 [ 107.183868] 0000000000000009 ffff8801583a1db8 ffffffff817d068c 0000000000000006 [ 107.183922] 0000000000000000 ffff8801583a1df8 ffffffff81039c22 ffffffffa023b31c [ 107.183975] ffffffffa01f6ba7 ffff880153c901c0 ffff880152058000 ffff8801596c59d8 [ 107.184028] Call Trace: [ 107.184048] [<ffffffff817d068c>] dump_stack+0x46/0x58 [ 107.184081] [<ffffffff81039c22>] warn_slowpath_common+0x81/0x9b [ 107.184133] [<ffffffffa023b31c>] ? i915_gem_dmabuf_release+0x3e/0x5e [i915] [ 107.184195] [<ffffffffa01f6ba7>] ? i915_gem_free_object+0xf3/0x19d [i915] [ 107.184237] [<ffffffff81039c56>] warn_slowpath_null+0x1a/0x1c [ 107.184279] [<ffffffffa01f6ba7>] i915_gem_free_object+0xf3/0x19d [i915] [ 107.184326] [<ffffffffa000aeaa>] drm_gem_object_free+0x2b/0x2d [drm] [ 107.184377] [<ffffffffa023b32f>] i915_gem_dmabuf_release+0x51/0x5e [i915] [ 107.184418] [<ffffffff8140d69e>] dma_buf_release+0x31/0x6d [ 107.184452] [<ffffffff8112249c>] __fput+0xf7/0x1ed [ 107.184483] [<ffffffff811225ca>] ____fput+0xe/0x10 [ 107.184513] [<ffffffff810577fa>] task_work_run+0x7e/0x98 [ 107.184547] [<ffffffff810025c2>] do_notify_resume+0x5a/0x6b [ 107.184582] [<ffffffff8135bc1e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 107.184621] [<ffffffff817def8a>] int_signal+0x12/0x17 [ 107.184652] ---[ end trace 302b8f14c10c9a4c ]--- [ 107.193258] ------------[ cut here ]------------
*** Bug 67392 has been marked as a duplicate of this bug. ***
Fix merged to dinq: commit 48ca155d15d439d5d035a3daf1c56ed1a30afb17 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 8 09:10:37 2013 +0200 drm/i915: unpin backing storage in dmabuf_unmap This fixes a WARN in i915_gem_free_object when the obj->pages_pin_count isn't 0. v2: Add locking to unmap, noticed by Chris Wilson. Note that even though we call unmap with our own dev->struct_mutex held that won't result in an immediate deadlock since we never go through the dma_buf interfaces for our own, reimported buffers. But it's still easy to blow up and anger lockdep, but that's already the case with our ->map implementation. Fixing this for real will involve per dma-buf ww mutex locking by the callers. And lots of fun. So go with the duct-tape approach for now. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com> Tested-by: Armin K. <krejzi@email.com> (v1) Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(In reply to comment #2) > Fix merged to dinq: > > commit 48ca155d15d439d5d035a3daf1c56ed1a30afb17 > Author: Daniel Vetter <daniel.vetter@ffwll.ch> > Date: Thu Aug 8 09:10:37 2013 +0200 > > drm/i915: unpin backing storage in dmabuf_unmap > > This fixes a WARN in i915_gem_free_object when the > obj->pages_pin_count isn't 0. > > v2: Add locking to unmap, noticed by Chris Wilson. Note that even > though we call unmap with our own dev->struct_mutex held that won't > result in an immediate deadlock since we never go through the dma_buf > interfaces for our own, reimported buffers. But it's still easy to > blow up and anger lockdep, but that's already the case with our ->map > implementation. Fixing this for real will involve per dma-buf ww mutex > locking by the callers. And lots of fun. So go with the duct-tape > approach for now. > > Cc: Chris Wilson <chris@chris-wilson.co.uk> > Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> > Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com> > Tested-by: Armin K. <krejzi@email.com> (v1) > Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> The Call Trace issue disappears, but after running it shows: Test requirement not met in function main, file prime_nv_api.c:522: Test requirement: (intel_fd != -1) Test requirement not met in function main, file prime_nv_api.c:523: Test requirement: (intel_fd2 != -1) DRM_IOCTL_I915_GEM_APERTURE failed: Bad file descriptor Assuming 131072kB available aperture size. May lead to reduced performance or incorrect rendering. get chip id failed: -1 [9] param: 4, val: 0 Test assertion failure function main, file prime_nv_api.c:527: Failed assertion: bufmgr prime_nv_api: drmtest.c:816: igt_fail: Assertion `!test_with_subtests' failed. So do I need to file a new bug?
(In reply to comment #3) > (In reply to comment #2) > > Fix merged to dinq: > > > > commit 48ca155d15d439d5d035a3daf1c56ed1a30afb17 > > Author: Daniel Vetter <daniel.vetter@ffwll.ch> > > Date: Thu Aug 8 09:10:37 2013 +0200 > > > > drm/i915: unpin backing storage in dmabuf_unmap > > > > This fixes a WARN in i915_gem_free_object when the > > obj->pages_pin_count isn't 0. > > > > v2: Add locking to unmap, noticed by Chris Wilson. Note that even > > though we call unmap with our own dev->struct_mutex held that won't > > result in an immediate deadlock since we never go through the dma_buf > > interfaces for our own, reimported buffers. But it's still easy to > > blow up and anger lockdep, but that's already the case with our ->map > > implementation. Fixing this for real will involve per dma-buf ww mutex > > locking by the callers. And lots of fun. So go with the duct-tape > > approach for now. > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk> > > Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> > > Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com> > > Tested-by: Armin K. <krejzi@email.com> (v1) > > Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > The Call Trace issue disappears, but after running it shows: > Test requirement not met in function main, file prime_nv_api.c:522: > Test requirement: (intel_fd != -1) > Test requirement not met in function main, file prime_nv_api.c:523: > Test requirement: (intel_fd2 != -1) > DRM_IOCTL_I915_GEM_APERTURE failed: Bad file descriptor > Assuming 131072kB available aperture size. > May lead to reduced performance or incorrect rendering. > get chip id failed: -1 [9] > param: 4, val: 0 > Test assertion failure function main, file prime_nv_api.c:527: > Failed assertion: bufmgr > prime_nv_api: drmtest.c:816: igt_fail: Assertion `!test_with_subtests' > failed. > > So do I need to file a new bug? At least on a machine with intel graphics setting opening the intel kernel driver and setting up the bufmgr (which is what fails above) should never fail. If this is not a duplicate of bug #68166 (where nouveau isn't available and the test falls over) then I think we need a new bug report for this.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > Fix merged to dinq: > > > > > > commit 48ca155d15d439d5d035a3daf1c56ed1a30afb17 > > > Author: Daniel Vetter <daniel.vetter@ffwll.ch> > > > Date: Thu Aug 8 09:10:37 2013 +0200 > > > > > > drm/i915: unpin backing storage in dmabuf_unmap > > > > > > This fixes a WARN in i915_gem_free_object when the > > > obj->pages_pin_count isn't 0. > > > > > > v2: Add locking to unmap, noticed by Chris Wilson. Note that even > > > though we call unmap with our own dev->struct_mutex held that won't > > > result in an immediate deadlock since we never go through the dma_buf > > > interfaces for our own, reimported buffers. But it's still easy to > > > blow up and anger lockdep, but that's already the case with our ->map > > > implementation. Fixing this for real will involve per dma-buf ww mutex > > > locking by the callers. And lots of fun. So go with the duct-tape > > > approach for now. > > > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk> > > > Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> > > > Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com> > > > Tested-by: Armin K. <krejzi@email.com> (v1) > > > Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> > > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> > > The Call Trace issue disappears, but after running it shows: > > Test requirement not met in function main, file prime_nv_api.c:522: > > Test requirement: (intel_fd != -1) > > Test requirement not met in function main, file prime_nv_api.c:523: > > Test requirement: (intel_fd2 != -1) > > DRM_IOCTL_I915_GEM_APERTURE failed: Bad file descriptor > > Assuming 131072kB available aperture size. > > May lead to reduced performance or incorrect rendering. > > get chip id failed: -1 [9] > > param: 4, val: 0 > > Test assertion failure function main, file prime_nv_api.c:527: > > Failed assertion: bufmgr > > prime_nv_api: drmtest.c:816: igt_fail: Assertion `!test_with_subtests' > > failed. > > > > So do I need to file a new bug? > > At least on a machine with intel graphics setting opening the intel kernel > driver and setting up the bufmgr (which is what fails above) should never > fail. > > If this is not a duplicate of bug #68166 (where nouveau isn't available and > the test falls over) then I think we need a new bug report for this. I reported one new bug #68253 to track this,It seems intel driver isn't available so testcase failed.
Closing old verified+fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.