summaryrefslogtreecommitdiffstats
path: root/kernel
diff options
context:
space:
mode:
authorDave Airlie <airlied@redhat.com>2012-08-21 16:40:07 +1000
committerLinus Torvalds <torvalds@linux-foundation.org>2012-08-21 09:08:50 -0700
commitec5da7f8dc023fc4dcbdd42e87dad231d2c2812d (patch)
tree42762ef00fbfcb1c48580fa9baf65e90ca99bcb5 /kernel
parent9160338de92c0305329be5163a76f849806e83de (diff)
downloadop-kernel-dev-ec5da7f8dc023fc4dcbdd42e87dad231d2c2812d.zip
op-kernel-dev-ec5da7f8dc023fc4dcbdd42e87dad231d2c2812d.tar.gz
fbcon: fix race condition between console lock and cursor timer
So we've had a fair few reports of fbcon handover breakage between efi/vesafb and i915 surface recently, so I dedicated a couple of days to finding the problem. Essentially the last thing we saw was the conflicting framebuffer message and that was all. So after much tracing with direct netconsole writes (printks under console_lock not so useful), I think I found the race. Thread A (driver load) Thread B (timer thread) unbind_con_driver -> | bind_con_driver -> | vc->vc_sw->con_deinit -> | fbcon_deinit -> | console_lock() | | | | fbcon_flashcursor timer fires | console_lock() <- blocked for A | | fbcon_del_cursor_timer -> del_timer_sync (BOOM) Of course because all of this is under the console lock, we never see anything, also since we also just unbound the active console guess what we never see anything. Hopefully this fixes the problem for anyone seeing vesafb->kms driver handoff. Signed-off-by: David Airlie <airlied@redhat.com> Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: stable@vger.kernel.org Tested-by: Josh Boyer <jwboyer@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud