System Environment: -------------------------- Platform: Pineview/Ironlake Kernel: (drm-intel-nightly)4c350bedd2f4a262ba6a62db8a0173261d18ca7a Merge: 77d718d 18097b9 Bug detailed description: ------------------------- Boot system. Call trace appears in dmesg.It happens on drm-intel-next-queued branch. It works well on drm-intel-fixes branch. Bisect shows:8f588cfc349bbbd8ae62a13679b9efba41645064 is the first bad commit. commit 8f588cfc349bbbd8ae62a13679b9efba41645064 Author: Ben Widawsky <ben@bwidawsk.net> AuthorDate: Wed Jul 17 12:19:03 2013 -0700 Commit: Daniel Vetter <daniel.vetter@ffwll.ch> CommitDate: Wed Jul 17 22:26:39 2013 +0200 drm/i915: Create VMAs Formerly: "drm/i915: Create VMAs (part 1)" In a previous patch, the notion of a VM was introduced. A VMA describes an area of part of the VM address space. A VMA is similar to the concept in the linux mm. However, instead of representing regular memory, a VMA is backed by a GEM BO. There may be many VMAs for a given object, one for each VM the object is to be used in. This may occur through flink, dma-buf, or a number of other transient states. Currently the code depends on only 1 VMA per object, for the global GTT (and aliasing PPGTT). The following patches will address this and make the rest of the infrastructure more suited v2: s/i915_obj/i915_gem_obj (Chris) v3: Only move an object to the now global unbound list if there are no more VMAs for the object which are bound into a VM (ie. the list is empty). v4: killed obj->gtt_space some reworks due to rebase v5: Free vma on error path (Imre) v6: Another missed vma free in i915_gem_object_bind_to_gtt error path (Imre) Fixed vma freeing in stolen preallocation (Imre) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Calltrace: [ 28.367837] Stack: [ 28.367838] ffff88010e6ae000 ffff88010dccd208 00000000fffffffb ffff88010de58000 [ 28.367839] ffff88010e6ae000 ffff88010dccc000 ffff88010dccc000 ffffffffa00a89e8 [ 28.367840] ffff88010e6ae000 ffff88010e6ae000 00000000fffffffb ffff88010dccc000 [ 28.367840] Call Trace: [ 28.367857] [<ffffffffa00a89e8>] ? intel_init_ring_buffer+0xce/0x32f [i915] [ 28.367868] [<ffffffffa0076a3c>] ? i915_gem_init_hw+0xac/0x1d8 [i915] [ 28.367880] [<ffffffffa0076c20>] ? i915_gem_init+0xb8/0x12a [i915] [ 28.367890] [<ffffffffa0066030>] ? i915_driver_load+0xbc9/0xe39 [i915] [ 28.367894] [<ffffffff81354818>] ? get_device+0x10/0x1c [ 28.367899] [<ffffffffa000e3a9>] ? drm_get_minor+0x1b5/0x20a [drm] [ 28.367903] [<ffffffffa000fd35>] ? drm_get_pci_dev+0x14d/0x254 [drm] [ 28.367905] [<ffffffff81357f4a>] ? driver_probe_device+0x19e/0x19e [ 28.367907] [<ffffffff812d6a61>] ? local_pci_probe+0x16/0x26 [ 28.367908] [<ffffffff812d731f>] ? pci_device_probe+0xbc/0xe0 [ 28.367909] [<ffffffff81357e36>] ? driver_probe_device+0x8a/0x19e [ 28.367910] [<ffffffff81357f9d>] ? __driver_attach+0x53/0x73 [ 28.367911] [<ffffffff813566f8>] ? bus_for_each_dev+0x4b/0x7c [ 28.367912] [<ffffffff8135766f>] ? bus_add_driver+0xdc/0x1fb [ 28.367913] [<ffffffff813584bc>] ? driver_register+0x89/0x101 [ 28.367914] [<ffffffffa00dd000>] ? 0xffffffffa00dcfff [ 28.367916] [<ffffffff81000257>] ? do_one_initcall+0x75/0x102 [ 28.367919] [<ffffffff8106c9ad>] ? load_module+0x17b2/0x1a8a [ 28.367921] [<ffffffff81069b4c>] ? sys_getegid16+0x40/0x40 [ 28.367922] [<ffffffff8106cd23>] ? SyS_init_module+0x9e/0xab [ 28.367925] [<ffffffff816f1fd2>] ? system_call_fastpath+0x16/0x1b [ 28.367934] Code: 79 f9 ff b8 f0 ff ff ff e9 32 01 00 00 49 8b 46 10 41 89 ed f6 40 09 01 74 11 48 8b 83 a0 00 00 00 4c 39 e0 75 28 e9 b8 00 00 00 <f6> 47 20 20 74 e9 4c 89 ee e8 ed bc ff ff 84 c0 75 dd 48 89 df [ 28.367946] RIP [<ffffffffa0076583>] i915_gem_object_set_cache_level+0xa0/0x1c1 [i915] [ 28.367946] RSP <ffff88010e7a1978> [ 28.367946] CR2: 0000000000000020 [ 28.367947] ---[ end trace c6651841bedf6116 ]---
Created attachment 82571 [details] dmesg
commit 2f63315692b1d3c055972ad33fc7168ae908b97b Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Jul 17 12:19:03 2013 -0700 drm/i915: Create VMAs Formerly: "drm/i915: Create VMAs (part 1)" In a previous patch, the notion of a VM was introduced. A VMA describes an area of part of the VM address space. A VMA is similar to the concept in the linux mm. However, instead of representing regular memory, a VMA is backed by a GEM BO. There may be many VMAs for a given object, one for each VM the object is to be used in. This may occur through flink, dma-buf, or a number of other transient states. Currently the code depends on only 1 VMA per object, for the global GTT (and aliasing PPGTT). The following patches will address this and make the rest of the infrastructure more suited v2: s/i915_obj/i915_gem_obj (Chris) v3: Only move an object to the now global unbound list if there are no more VMAs for the object which are bound into a VM (ie. the list is empty). v4: killed obj->gtt_space some reworks due to rebase v5: Free vma on error path (Imre) v6: Another missed vma free in i915_gem_object_bind_to_gtt error path (Imre) Fixed vma freeing in stolen preallocation (Imre) Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Imre Deak <imre.deak@intel.com> [danvet: Squash in fixup from Ben to not deref a non-existing vma in set_cache_level, reported by Chris.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Verified.Fixed.
Closing old verified.
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.