Panic in i915kms on power mode change (HD 4400) #5
Assignees
Comments
|
I was able to reproduce this on my laptop and was able to capture what looks like a valid core. here is the bt: |
|
My last commit removes the panic and should make this work, please pull and test |
|
It does indeed! Thanks! On the other hand, it has the minor unwanted side effect of disabling automatic brightness change on power mode switching, as provided by the acpi_video(4) driver with the 3.9 DRM branch. Setting brightness through sysctl works though. Should I open another issue to keep track of this? |
|
Please scratch that… after updating to the latest revision (34475b8) the brightness changes automatically as defined by the acpi_video(4) settings. Thanks again! |
mattmacy
pushed a commit
that referenced
this issue
Jun 24, 2016
Drop scan generation number and node table scan lock - the only place where ni_scangen is checked is in ieee80211_timeout_stations() (and it is used to prevent duplicate checking of the same node); node scan lock protects only this variable + node table scan generation number. This will fix (at least) next LOR (hostap mode): lock order reversal: 1st 0xc175f84c urtwm0_scan_loc (urtwm0_scan_loc) @ /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:2019 2nd 0xc175e018 urtwm0_com_lock (urtwm0_com_lock) @ /usr/src/sys/modules/wlan/../../net80211/ieee80211_node.c:2693 stack backtrace: #0 0xa070d1c5 at witness_debugger+0x75 #1 0xa070d0f6 at witness_checkorder+0xd46 #2 0xa0694cce at __mtx_lock_flags+0x9e #3 0xb03ad9ef at ieee80211_node_leave+0x12f #4 0xb03afd13 at ieee80211_timeout_stations+0x483 #5 0xb03aa1c2 at ieee80211_node_timeout+0x42 #6 0xa06c6fa1 at softclock_call_cc+0x1e1 #7 0xa06c7518 at softclock+0xc8 #8 0xa06789ae at intr_event_execute_handlers+0x8e #9 0xa0678fa0 at ithread_loop+0x90 #10 0xa0675fbe at fork_exit+0x7e #11 0xa08af910 at fork_trampoline+0x8 In addition to the above: * switch to ieee80211_iterate_nodes(); * do not assert that node table lock is held, while calling node_age(); that's not really needed (there are no resources, which can be protected by this lock) + this fixes LOR/deadlock between ieee80211_timeout_stations() and ieee80211_set_tim() (easy to reproduce in HOSTAP mode while sending something to an STA with enabled power management). Tested: * (avos) urtwn0, hostap mode * (adrian) AR9380, STA mode * (adrian) AR9380, AR9331, AR9580, hostap mode Notes: * This changes the net80211 internals, so you have to recompile all of it and the wifi drivers. Submitted by: avos Approved by: re (delphij) Differential Revision: https://reviews.freebsd.org/D6833
mattmacy
pushed a commit
that referenced
this issue
Aug 9, 2016
commit e2c8b8701e2d moved modeset locking inside resume/suspend
functions, but missed a code path only executed on lid close/open
on older hardware. The result was a deadlock when closing and
opening the lid without suspending on such hardware:
=============================================
[ INFO: possible recursive locking detected ]
4.6.0-rc1 #385 Not tainted
---------------------------------------------
kworker/0:3/88 is trying to acquire lock:
(&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]
but task is already holding lock:
(&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&dev->mode_config.mutex);
lock(&dev->mode_config.mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
7 locks held by kworker/0:3/88:
#0: ("kacpi_notify"){++++.+}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b
#1: ((&dpc->work)#2){+.+.+.}, at: [<ffffffff81068dfc>] process_one_work+0x14a/0x50b
#2: ((acpi_lid_notifier).rwsem){++++.+}, at: [<ffffffff8106f874>] __blocking_notifier_call_chain+0x34/0x65
#3: (&dev_priv->modeset_restore_lock){+.+.+.}, at: [<ffffffffa0664cf6>] intel_lid_notify+0x3c/0xd9 [i915]
#4: (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffffa02d0d4f>] drm_modeset_lock_all+0x3e/0xa6 [drm]
#5: (crtc_ww_class_acquire){+.+.+.}, at: [<ffffffffa02d0d59>] drm_modeset_lock_all+0x48/0xa6 [drm]
#6: (crtc_ww_class_mutex){+.+.+.}, at: [<ffffffffa02d0b2a>] modeset_lock+0x13c/0x1cd [drm]
stack backtrace:
CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
Workqueue: kacpi_notify acpi_os_execute_deferred
0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0
ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70
000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0
Call Trace:
[<ffffffff8124af06>] dump_stack+0x67/0x90
[<ffffffff8108f547>] __lock_acquire+0xdb5/0xf71
[<ffffffff8108bd2c>] ? look_up_lock_class+0xbe/0x10a
[<ffffffff8108fae2>] lock_acquire+0x137/0x1cb
[<ffffffff8108fae2>] ? lock_acquire+0x137/0x1cb
[<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
[<ffffffff8148202f>] mutex_lock_nested+0x7e/0x3a4
[<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
[<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
[<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
[<ffffffffa063e6a4>] intel_display_resume+0x4a/0x12f [i915]
[<ffffffffa063e6a4>] ? intel_display_resume+0x4a/0x12f [i915]
[<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
[<ffffffffa02d0b2a>] ? modeset_lock+0x13c/0x1cd [drm]
[<ffffffffa02d0bf7>] ? drm_modeset_lock+0x17/0x24 [drm]
[<ffffffffa02d0c8b>] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm]
[<ffffffffa0664d6a>] intel_lid_notify+0xb0/0xd9 [i915]
[<ffffffff8106f4c6>] notifier_call_chain+0x4a/0x6c
[<ffffffff8106f88d>] __blocking_notifier_call_chain+0x4d/0x65
[<ffffffff8106f8b9>] blocking_notifier_call_chain+0x14/0x16
[<ffffffffa0011215>] acpi_lid_send_state+0x83/0xad [button]
[<ffffffffa00112a6>] acpi_button_notify+0x41/0x132 [button]
[<ffffffff812b07df>] acpi_device_notify+0x19/0x1b
[<ffffffff812c8570>] acpi_ev_notify_dispatch+0x49/0x64
[<ffffffff812ab9fb>] acpi_os_execute_deferred+0x14/0x20
[<ffffffff81068f17>] process_one_work+0x265/0x50b
[<ffffffff810696f5>] worker_thread+0x1fc/0x2dd
[<ffffffff810694f9>] ? rescuer_thread+0x309/0x309
[<ffffffff810694f9>] ? rescuer_thread+0x309/0x309
[<ffffffff8106e2d6>] kthread+0xe0/0xe8
[<ffffffff8107bc47>] ? local_clock+0x19/0x22
[<ffffffff81484f42>] ret_from_fork+0x22/0x40
[<ffffffff8106e1f6>] ? kthread_create_on_node+0x1b5/0x1b5
Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459328913-13719-1-git-send-email-bjorn@mork.no
mattmacy
pushed a commit
that referenced
this issue
Aug 16, 2016
drm_connector_register_all requires a few too many locks because our
connector_list locking is busted. Add another FIXME+hack to work
around this. This should address the below lockdep splat:
======================================================
[ INFO: possible circular locking dependency detected ]
4.7.0-rc5+ #524 Tainted: G O
-------------------------------------------------------
kworker/u8:0/6 is trying to acquire lock:
(&dev->mode_config.mutex){+.+.+.}, at: [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120
but task is already holding lock:
((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff810ac195>] __blocking_notifier_call_chain+0x35/0x70
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 ((fb_notifier_list).rwsem){++++.+}:
[<ffffffff810df611>] lock_acquire+0xb1/0x200
[<ffffffff819a55b4>] down_write+0x44/0x80
[<ffffffff810abf91>] blocking_notifier_chain_register+0x21/0xb0
[<ffffffff814c7448>] fb_register_client+0x18/0x20
[<ffffffff814c6c86>] backlight_device_register+0x136/0x260
[<ffffffffa0127eb2>] intel_backlight_device_register+0xa2/0x160 [i915]
[<ffffffffa00f46be>] intel_connector_register+0xe/0x10 [i915]
[<ffffffffa0112bfb>] intel_dp_connector_register+0x1b/0x80 [i915]
[<ffffffff8159dfea>] drm_connector_register+0x4a/0x80
[<ffffffff8159fe44>] drm_connector_register_all+0x64/0xf0
[<ffffffff815a2a64>] drm_modeset_register_all+0x174/0x1c0
[<ffffffff81599b72>] drm_dev_register+0xc2/0xd0
[<ffffffffa00621d7>] i915_driver_load+0x1547/0x2200 [i915]
[<ffffffffa006d80f>] i915_pci_probe+0x4f/0x70 [i915]
[<ffffffff814a2135>] local_pci_probe+0x45/0xa0
[<ffffffff814a349b>] pci_device_probe+0xdb/0x130
[<ffffffff815c07e3>] driver_probe_device+0x223/0x440
[<ffffffff815c0ad5>] __driver_attach+0xd5/0x100
[<ffffffff815be386>] bus_for_each_dev+0x66/0xa0
[<ffffffff815c002e>] driver_attach+0x1e/0x20
[<ffffffff815bf9be>] bus_add_driver+0x1ee/0x280
[<ffffffff815c1810>] driver_register+0x60/0xe0
[<ffffffff814a1a10>] __pci_register_driver+0x60/0x70
[<ffffffffa01a905b>] i915_init+0x5b/0x62 [i915]
[<ffffffff8100042d>] do_one_initcall+0x3d/0x150
[<ffffffff811a935b>] do_init_module+0x5f/0x1d9
[<ffffffff81124416>] load_module+0x20e6/0x27e0
[<ffffffff81124d63>] SYSC_finit_module+0xc3/0xf0
[<ffffffff81124dae>] SyS_finit_module+0xe/0x10
[<ffffffff819a83a9>] entry_SYSCALL_64_fastpath+0x1c/0xac
-> #0 (&dev->mode_config.mutex){+.+.+.}:
[<ffffffff810df0ac>] __lock_acquire+0x10fc/0x1260
[<ffffffff810df611>] lock_acquire+0xb1/0x200
[<ffffffff819a3097>] mutex_lock_nested+0x67/0x3c0
[<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120
[<ffffffff8158f79b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
[<ffffffff8158f81d>] drm_fb_helper_set_par+0x2d/0x50
[<ffffffffa0105f7a>] intel_fbdev_set_par+0x1a/0x60 [i915]
[<ffffffff814c13c6>] fbcon_init+0x586/0x610
[<ffffffff8154d16a>] visual_init+0xca/0x130
[<ffffffff8154e611>] do_bind_con_driver+0x1c1/0x3a0
[<ffffffff8154eaf6>] do_take_over_console+0x116/0x180
[<ffffffff814bd3a7>] do_fbcon_takeover+0x57/0xb0
[<ffffffff814c1e48>] fbcon_event_notify+0x658/0x750
[<ffffffff810abcae>] notifier_call_chain+0x3e/0xb0
[<ffffffff810ac1ad>] __blocking_notifier_call_chain+0x4d/0x70
[<ffffffff810ac1e6>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff814c748b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff814c86b1>] register_framebuffer+0x251/0x330
[<ffffffff8158fa9f>] drm_fb_helper_initial_config+0x25f/0x3f0
[<ffffffffa0106b48>] intel_fbdev_initial_config+0x18/0x30 [i915]
[<ffffffff810adfd8>] async_run_entry_fn+0x48/0x150
[<ffffffff810a3947>] process_one_work+0x1e7/0x750
[<ffffffff810a3efb>] worker_thread+0x4b/0x4f0
[<ffffffff810aad4f>] kthread+0xef/0x110
[<ffffffff819a85ef>] ret_from_fork+0x1f/0x40
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((fb_notifier_list).rwsem);
lock(&dev->mode_config.mutex);
lock((fb_notifier_list).rwsem);
lock(&dev->mode_config.mutex);
*** DEADLOCK ***
6 locks held by kworker/u8:0/6:
#0: ("events_unbound"){.+.+.+}, at: [<ffffffff810a38c9>] process_one_work+0x169/0x750
#1: ((&entry->work)){+.+.+.}, at: [<ffffffff810a38c9>] process_one_work+0x169/0x750
#2: (registration_lock){+.+.+.}, at: [<ffffffff814c8487>] register_framebuffer+0x27/0x330
#3: (console_lock){+.+.+.}, at: [<ffffffff814c86ce>] register_framebuffer+0x26e/0x330
#4: (&fb_info->lock){+.+.+.}, at: [<ffffffff814c78dd>] lock_fb_info+0x1d/0x40
#5: ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff810ac195>] __blocking_notifier_call_chain+0x35/0x70
stack backtrace:
CPU: 2 PID: 6 Comm: kworker/u8:0 Tainted: G O 4.7.0-rc5+ #524
Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLKRVPA.X64.0138.B33.1606250842 06/25/2016
Workqueue: events_unbound async_run_entry_fn
0000000000000000 ffff8800758577f0 ffffffff814507a5 ffffffff828b9900
ffffffff828b9900 ffff880075857830 ffffffff810dc6fa ffff880075857880
ffff88007584d688 0000000000000005 0000000000000006 ffff88007584d6b0
Call Trace:
[<ffffffff814507a5>] dump_stack+0x67/0x92
[<ffffffff810dc6fa>] print_circular_bug+0x1aa/0x200
[<ffffffff810df0ac>] __lock_acquire+0x10fc/0x1260
[<ffffffff810df611>] lock_acquire+0xb1/0x200
[<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120
[<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120
[<ffffffff819a3097>] mutex_lock_nested+0x67/0x3c0
[<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120
[<ffffffff810fa85f>] ? rcu_read_lock_sched_held+0x7f/0x90
[<ffffffff81208218>] ? kmem_cache_alloc_trace+0x248/0x2b0
[<ffffffff815afdc5>] ? drm_modeset_lock_all+0x25/0x120
[<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120
[<ffffffff8158f79b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
[<ffffffff8158f81d>] drm_fb_helper_set_par+0x2d/0x50
[<ffffffffa0105f7a>] intel_fbdev_set_par+0x1a/0x60 [i915]
[<ffffffff814c13c6>] fbcon_init+0x586/0x610
[<ffffffff8154d16a>] visual_init+0xca/0x130
[<ffffffff8154e611>] do_bind_con_driver+0x1c1/0x3a0
[<ffffffff8154eaf6>] do_take_over_console+0x116/0x180
[<ffffffff814bd3a7>] do_fbcon_takeover+0x57/0xb0
[<ffffffff814c1e48>] fbcon_event_notify+0x658/0x750
[<ffffffff810abcae>] notifier_call_chain+0x3e/0xb0
[<ffffffff810ac1ad>] __blocking_notifier_call_chain+0x4d/0x70
[<ffffffff810ac1e6>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff814c748b>] fb_notifier_call_chain+0x1b/0x20
[<ffffffff814c86b1>] register_framebuffer+0x251/0x330
[<ffffffff815b7e8d>] ? vga_switcheroo_client_fb_set+0x5d/0x70
[<ffffffff8158fa9f>] drm_fb_helper_initial_config+0x25f/0x3f0
[<ffffffffa0106b48>] intel_fbdev_initial_config+0x18/0x30 [i915]
[<ffffffff810adfd8>] async_run_entry_fn+0x48/0x150
[<ffffffff810a3947>] process_one_work+0x1e7/0x750
[<ffffffff810a38c9>] ? process_one_work+0x169/0x750
[<ffffffff810a3efb>] worker_thread+0x4b/0x4f0
[<ffffffff810a3eb0>] ? process_one_work+0x750/0x750
[<ffffffff810aad4f>] kthread+0xef/0x110
[<ffffffff819a85ef>] ret_from_fork+0x1f/0x40
[<ffffffff810aac60>] ? kthread_stop+0x2e0/0x2e0
v2: Rebase onto the right branch (hand-editing patches ftw) and add more
reporters.
Reported-by: Imre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Jiri Kosina <jikos@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
mjoras
pushed a commit
to mjoras/freebsd-base-graphics
that referenced
this issue
Jun 16, 2017
OpenRC version of sendmail
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
With a Haswell (HD 4400) GPU laptop, changing the power mode (plugging or unplugging the power cord) leads to instant panic, while with the drm-next-3.9 branch, switching AC/battery modifies backlight value up and down without issues.
To reproduce:
[plug / unplug the power cord (the result is exactly the same)]
panic: IMPLEMENT ME
…then the backtrace (picture).
The text was updated successfully, but these errors were encountered: