From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751618AbXBVNi2 (ORCPT ); Thu, 22 Feb 2007 08:38:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751624AbXBVNi2 (ORCPT ); Thu, 22 Feb 2007 08:38:28 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]:10970 "EHLO nz-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751616AbXBVNi1 (ORCPT ); Thu, 22 Feb 2007 08:38:27 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=ETB/S3UwvvTqVWmPU4q7LhRnISpp4MnZoqZV04kjanPiktitzELjQ2KxvPnh4DD4bQT1jDU6I4lvE/IGBIbtAiKibYboGdBzlnurMH6bc6Ye2eA9JSS8a4GZC4XvVjVMH65oBL1XN4TYBGKEKEqg5N7G4dMlgZyzoBo3ZB67TIs= Subject: Re: [BUG] at drivers/char/vt.c:3332 do_blank_screen() on resume From: "Antonino A. Daplas" To: caglar@pardus.org.tr Cc: Andrew Morton , Pavel Machek , lkml , spock@gentoo.org In-Reply-To: <200702221453.18153.caglar@pardus.org.tr> References: <200702090838.21060.caglar@pardus.org.tr> <200702151300.41343.caglar@pardus.org.tr> <1172101421.4217.20.camel@daplas> <200702221453.18153.caglar@pardus.org.tr> Content-Type: text/plain; charset=utf-8 Date: Thu, 22 Feb 2007 21:41:11 +0800 Message-Id: <1172151671.4306.13.camel@daplas> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2007-02-22 at 14:53 +0200, S.Çağlar Onur wrote: > Hi; > > 22 Şub 2007 Per tarihinde, Antonino A. Daplas şunları yazmıştı: > > On Thu, 2007-02-15 at 13:00 +0200, S.Çağlar Onur wrote: > > > 15 Şub 2007 Per tarihinde, Andrew Morton şunları yazmıştı: > > > > On Thu, 15 Feb 2007 11:40:32 +0100 Pavel Machek wrote: > > > > > Contact fbcon people... > > > > > > > > There aren't any, basically. Since Tony disappeared James has been > > > > helping out but doesn't have a lot of time. So we're pretty much on > > > > our own with problems in this area. > > > > > > I already sent same mail to > > > linux-fbdev-devel mailing lists at sf.net with hope :) > > > > > > Cheers > > > > Interesting... It does look like this was triggered by calling > > do_blank_screen() without taking the console semaphore, but > > console_callback() should have taken that. > > > > Second point is that vesafb does not have any blanking functionality, > > thus it should not trigger fbcon_event_notify(). My guess is you are > > using an out-of-tree vesafb? > > As i wrote we are using vesafb-tng [http://dev.gentoo.org/~spock/projects/] > for a long time but this hits me only with 2.6.20 and only after > suspend2disk, so im adding Michał Januszewski to CC if this is vesafb-tng > related :). > Ah, and you have fb_splash too. That's why the tracing was not what I expected it to be. Try using video=vesafb:noblank to disable hardware blanking and find out if you can still reproduce the oops. > > BUG: at drivers/char/vt.c:3332 do_blank_screen() > > [] do_blank_screen+0x4e/0x218 > > [] fbcon_event_notify+0x8f1/0xa1e > > [] extract_buf+0xac/0xe1 > > [] __switch_to+0xeb/0x15d > > [] __sched_text_start+0x865/0x929 > > [] bit_cursor+0x4c8/0x50b > > [] wait_for_completion+0x79/0xaf > > [] default_wake_function+0x0/0xc > > [] notifier_call_chain+0x19/0x32 > > [] blocking_notifier_call_chain+0x23/0x33 > > [] fb_blank+0x4a/0x53 > > [] fbcon_blank+0xf4/0x1e3 > > [] fbcon_cursor+0x21c/0x250 > > [] bit_cursor+0x0/0x50b > > [] lock_timer_base+0x15/0x2f > > [] try_to_del_timer_sync+0x44/0x4a > > [] fbcon_blank+0x0/0x1e3 > > [] do_blank_screen+0x1b1/0x218 > > [] console_callback+0xaf/0xbf > > [] run_workqueue+0x85/0x135 > > [] console_callback+0x0/0xbf > > [] worker_thread+0x10a/0x136 > > [] default_wake_function+0x0/0xc > > [] worker_thread+0x0/0x136 > > [] kthread+0xb2/0xdc > > [] kthread+0x0/0xdc > > [] kernel_thread_helper+0x7/0x10 > > > > As for the last tracing, it looks to be valid bug to me. > > complete_change_console() should be called with the console sem > > taken. I'll look into this. > > If testing needed just ask please :) After grepping for change_console, all callers of change_console and complete_change_console are acquiring the console semaphore, so I really don't know what's going on here... Since you are using a non-vanilla kernel, can you just do a grep change_console of the kernel source and see if you can find a caller that missed doing an acquire_console_sem(). > > > BUG: at drivers/char/vt.c:3486 set_palette() > > [] set_palette+0x41/0x59 > > [] redraw_screen+0x110/0x17e > > [] complete_change_console+0x2a/0xba > > [] console_callback+0x45/0xbf > > [] run_workqueue+0x85/0x135 > > [] console_callback+0x0/0xbf > > [] worker_thread+0x10a/0x136 > > [] default_wake_function+0x0/0xc > > [] worker_thread+0x0/0x136 > > [] kthread+0xb2/0xdc > > [] kthread+0x0/0xdc > > [] kernel_thread_helper+0x7/0x10 > > > > Tony > > Cheers Tony