Created attachment 109316 [details] dmesg ==System Environment== -------------------------- Regression: not sure, it also has bug 83868 Non-working platforms: HSW ==kernel== -------------------------- drm-intel-nightly/de6d6ca380bba4f962f942089b0a212d9b3977c1 ==Bug detailed description== ----------------------------- It only happens one HSW machine(same as bug 85541, bug 85787, bug 85885). Clean boot system, run ./drv_module_reload, it reports call trace(the call trace looks like bug 85885). then run dmesg -c and run ./drv_module_reload, it doesn't have call trace. output: unbinding /sys/class/vtconsole/vtcon0/: (M) frame buffer device module successfully unloaded module successfully loaded again [ 46.460577] ====================================================== [ 46.460577] [ INFO: possible circular locking dependency detected ] [ 46.460578] 3.18.0-rc3_drm-intel-nightly_de6d6c_20141111_debug+ #1416 Not tainted [ 46.460579] ------------------------------------------------------- [ 46.460579] drv_module_relo/4038 is trying to acquire lock: [ 46.460585] (console_lock){+.+.+.}, at: [<ffffffff8142ced1>] store_bind+0x1f0/0x221 [ 46.460585] but task is already holding lock: [ 46.460588] (s_active#16){++++.+}, at: [<ffffffff811a0756>] kernfs_fop_write+0xaf/0x132 [ 46.460588] which lock already depends on the new lock. [ 46.460589] the existing dependency chain (in reverse order) is: [ 46.460590] -> #1 (s_active#16){++++.+}: [ 46.460592] [<ffffffff81075c74>] lock_acquire+0xd3/0x10d [ 46.460594] [<ffffffff8119efda>] __kernfs_remove+0x132/0x285 [ 46.460595] [<ffffffff8119fe23>] kernfs_remove_by_name_ns+0x70/0x8e [ 46.460596] [<ffffffff811a1354>] sysfs_remove_file_ns+0x15/0x17 [ 46.460598] [<ffffffff8144a200>] device_remove_file+0x19/0x1b [ 46.460600] [<ffffffff8142b56d>] do_unregister_con_driver+0x60/0xdd [ 46.460618] [<ffffffffa011902a>] i915_driver_load+0x5c7/0xe59 [i915] [ 46.460625] [<ffffffffa0013cf7>] drm_dev_register+0x84/0xfd [drm] [ 46.460630] [<ffffffffa0016380>] drm_get_pci_dev+0xff/0x1b6 [drm] [ 46.460634] [<ffffffffa00942f2>] i915_pci_probe+0x45/0x4e [i915] [ 46.460637] [<ffffffff813bcb18>] local_pci_probe+0x3d/0x83 [ 46.460638] [<ffffffff813bcdef>] pci_device_probe+0xcb/0xf1 [ 46.460640] [<ffffffff8144dc3a>] driver_probe_device+0xa6/0x1d7 [ 46.460641] [<ffffffff8144ddce>] __driver_attach+0x63/0x87 [ 46.460642] [<ffffffff8144c29a>] bus_for_each_dev+0x5f/0x91 [ 46.460643] [<ffffffff8144d7a9>] driver_attach+0x1e/0x20 [ 46.460644] [<ffffffff8144d437>] bus_add_driver+0xf6/0x1db [ 46.460646] [<ffffffff8144e4dc>] driver_register+0x8c/0xc3 [ 46.460647] [<ffffffff813bcee4>] __pci_register_driver+0x62/0x67 [ 46.460652] [<ffffffffa001648f>] drm_pci_init+0x58/0xd9 [drm] [ 46.460653] [<ffffffffa017108a>] 0xffffffffa017108a [ 46.460655] [<ffffffff8100031d>] do_one_initcall+0xef/0x18e [ 46.460656] [<ffffffff810a68ab>] load_module+0x1a91/0x1d98 [ 46.460657] [<ffffffff810a6c59>] SyS_init_module+0xa7/0xb6 [ 46.460659] [<ffffffff81842552>] system_call_fastpath+0x12/0x17 [ 46.460660] -> #0 (console_lock){+.+.+.}: [ 46.460661] [<ffffffff8107500d>] __lock_acquire+0x10ac/0x1803 [ 46.460662] [<ffffffff81075c74>] lock_acquire+0xd3/0x10d [ 46.460664] [<ffffffff81081579>] console_lock+0x41/0x60 [ 46.460665] [<ffffffff8142ced1>] store_bind+0x1f0/0x221 [ 46.460666] [<ffffffff81449a80>] dev_attr_store+0x18/0x24 [ 46.460667] [<ffffffff811a14fb>] sysfs_kf_write+0x4a/0x52 [ 46.460668] [<ffffffff811a0790>] kernfs_fop_write+0xe9/0x132 [ 46.460670] [<ffffffff8113c7f4>] vfs_write+0xbe/0x19a [ 46.460672] [<ffffffff8113cafe>] SyS_write+0x4a/0x91 [ 46.460673] [<ffffffff81842552>] system_call_fastpath+0x12/0x17 [ 46.460673] other info that might help us debug this: ==Reproduce steps== ---------------------------- 1. clean boot system 2. ./drv_module_reload
Is this really only an issue on hsw? Note that for this backtrace you need to have lockdep enabled (CONFIG_PROVE_LOCKING), please double-check that other tested machines have that config option enabled.
(In reply to Daniel Vetter from comment #1) > Is this really only an issue on hsw? > > Note that for this backtrace you need to have lockdep enabled > (CONFIG_PROVE_LOCKING), please double-check that other tested machines have > that config option enabled. I checked on SNB and BDW, and didn't reproduce this issue. CONFIG_PROVE_LOCKING=y
I checked on a HSW machine with a kernel that had CONFIG_PROVE_LOCKING=y and could't reproduce this bug. $ grep PROVE .config CONFIG_PROVE_LOCKING=y kernel: commit 3b18622741df60bb73608472310ceecc6bbde04b Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Dec 3 17:57:29 2014 +0100 drm-intel-nightly: 2014y-12m-03d-16h-57m-04s UTC integration manifest
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.