[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#686284: i915 locks up my Thinkpad X30 (using a GMA 82830)

tags 686284 + upstream patch moreinfo

Hi Stefan,

Stefan Monnier wrote:

> forwarded 686284 https://bugs.freedesktop.org/show_bug.cgi?id=54615

That was fast. :)

Please test the attached patch against a 3.2.y kernel, for example
by using the following instructions:

 0. prerequisites:

	apt-get install git build-essential

 1. get the kernel history, if you don't already have it:

	git clone \

 2. fetch point releases:

	cd linux
	git remote add stable \
	git fetch stable

 3. configure, build, test:

	git checkout stable/linux-3.2.y
	cp /boot/config-$(uname -r) .config; # current configuration
	scripts/config --disable DEBUG_INFO
	make localmodconfig; # optional: minimize configuration
	make deb-pkg; # optionally with -j<num> for parallel build
	dpkg -i ../<name of package>; # as root
	... test test test ...

     Hopefully it reproduces the bug.  So

 4. try the patch:

	cd linux
	git am -3sc /path/to/the/patch
	make deb-pkg; # maybe with -j4
	dpkg -i ../<name of package>; # as root
	... test test test ...

If we're lucky, it will avoid the lockup during boot.  The spurious
enabling of kms is presumably a separate issue which we can look into

Thanks again for the quick feedback.

From: Dave Airlie <airlied@redhat.com>
Date: Tue, 21 Aug 2012 16:29:47 +1000
Subject: fbcon: fix race condition between console lock and cursor timer (v1.1)

commit d8636a2717bb3da2a7ce2154bf08de90bb8c87b0 upstream.

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 ->

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.

v1.1: add comment suggestion from Alan.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
 drivers/video/console/fbcon.c |    9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index 8745637..bf9a9b7 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -373,8 +373,15 @@ static void fb_flashcursor(struct work_struct *work)
 	struct vc_data *vc = NULL;
 	int c;
 	int mode;
+	int ret;
+	/* FIXME: we should sort out the unbind locking instead */
+	/* instead we just fail to flash the cursor if we can't get
+	 * the lock instead of blocking fbcon deinit */
+	ret = console_trylock();
+	if (ret == 0)
+		return;
-	console_lock();
 	if (ops && ops->currcon != -1)
 		vc = vc_cons[ops->currcon].d;

Reply to: