Quoting Matthew Auld (2017-11-10 23:40:07) > On 10 November 2017 at 23:24, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > Move all of the i915->mm initialisation to a private function that can > > be reused by the mock i915 device to save forgetting any more steps. > > > > For example, > > <7>[ 1542.046332] [IGT] drv_selftest: starting subtest mock_objects > > <4>[ 1542.123924] Setting dangerous option mock_selftests - tainting kernel > > <6>[ 1542.167941] i915: Performing mock selftests with st_random_seed=0x246f5ab5 st_timeout=1000 > > <4>[ 1542.178012] INFO: trying to register non-static key. > > <4>[ 1542.178027] the code is fine but needs lockdep annotation. > > <4>[ 1542.178032] turning off the locking correctness validator. > > <4>[ 1542.178041] CPU: 3 PID: 6008 Comm: kworker/3:7 Tainted: G U 4.14.0-rc8-CI-CI_DRM_3332+ #1 > > <4>[ 1542.178049] Hardware name: /NUC6CAYB, BIOS AYAPLCEL.86A.0040.2017.0619.1722 06/19/2017 > > <4>[ 1542.178144] Workqueue: events __i915_gem_free_work [i915] > > <4>[ 1542.178152] Call Trace: > > <4>[ 1542.178163] dump_stack+0x68/0x9f > > <4>[ 1542.178170] register_lock_class+0x3fd/0x580 > > <4>[ 1542.178177] ? unwind_next_frame+0x14/0x20 > > <4>[ 1542.178184] ? __save_stack_trace+0x73/0xd0 > > <4>[ 1542.178191] __lock_acquire+0xa4/0x1b00 > > <4>[ 1542.178254] ? __i915_gem_free_work+0x28/0xa0 [i915] > > <4>[ 1542.178261] ? __lock_acquire+0x4ab/0x1b00 > > <4>[ 1542.178268] lock_acquire+0xb0/0x200 > > <4>[ 1542.178273] ? lock_acquire+0xb0/0x200 > > <4>[ 1542.178336] ? __i915_gem_free_work+0x28/0xa0 [i915] > > <4>[ 1542.178344] _raw_spin_lock+0x32/0x50 > > <4>[ 1542.178405] ? __i915_gem_free_work+0x28/0xa0 [i915] > > <4>[ 1542.178468] __i915_gem_free_work+0x28/0xa0 [i915] > > <4>[ 1542.178476] process_one_work+0x221/0x650 > > <4>[ 1542.178483] worker_thread+0x4e/0x3c0 > > <4>[ 1542.178489] kthread+0x114/0x150 > > <4>[ 1542.178494] ? process_one_work+0x650/0x650 > > <4>[ 1542.178499] ? kthread_create_on_node+0x40/0x40 > > <4>[ 1542.178506] ret_from_fork+0x27/0x40 > > > > v2: Fish out i915->mm.object_stat_lock which was being inited over in > > i915_drv.c (Matthew) > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Matthew Auld <matthew.auld@xxxxxxxxx> > Reviewed-by: Matthew Auld <matthew.auld@xxxxxxxxx> Thanks, and pushed. One thing we to consider is how to reign live_hugepages in a bit or complain about the owatch timeout being too short. And if you have a moment to spare, the shards suggest that there is a kernel memory leak but not being reported by the standard mm checks on unload. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
