Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933924AbXFEVzq (ORCPT ); Tue, 5 Jun 2007 17:55:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932433AbXFEVzi (ORCPT ); Tue, 5 Jun 2007 17:55:38 -0400 Received: from ogre.sisk.pl ([217.79.144.158]:45819 "EHLO ogre.sisk.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932088AbXFEVzh (ORCPT ); Tue, 5 Jun 2007 17:55:37 -0400 From: "Rafael J. Wysocki" To: Pavel Machek Subject: Re: Linux 2.6.22-rc4 Date: Wed, 6 Jun 2007 00:01:14 +0200 User-Agent: KMail/1.9.5 Cc: Ingo Molnar , Linus Torvalds , Michal Piotrowski , Linux Kernel Mailing List , linux-pm@lists.linux-foundation.org, Peter Zijlstra References: <20070605193718.GB24877@elte.hu> <20070605201954.GB4424@elf.ucw.cz> In-Reply-To: <20070605201954.GB4424@elf.ucw.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706060001.15081.rjw@sisk.pl> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2800 Lines: 63 On Tuesday, 5 June 2007 22:19, Pavel Machek wrote: > Hi! > > > > > [ 116.733327] PM: suspend-to-disk mode set to 'shutdown' [ > > > > 116.738849] swsusp: Basic memory bitmaps created [ 116.745353] > > > > Stopping tasks ... WARNING: at > > > > /home/devel/linux-git/kernel/lockdep.c:2414 check_flags() > > > > > > [ 116.755052] irq event stamp: 69 > > > > [ 116.755060] hardirqs last enabled at (69): [] syscall_exit_work+0x11/0x26 > > > > [ 116.755084] hardirqs last disabled at (68): [] syscall_exit+0x9/0x1a > > > > [ 116.755109] softirqs last enabled at (0): [] copy_process+0x4dd/0x1286 > > > > [ 116.755139] softirqs last disabled at (0): [<00000000>] 0x0 > > > > [ 116.945776] done. > > > > > Well, it's harmless in the sense that "yeah, the system still works", > > > but it does seem to be a real bug. We have hardware interrupts > > > disabled when we _think_ we should have them on, so our irq tracking > > > is off. > > > > > > Ingo, do you see what's up? It looks like we got a signal to a process > > > that just got created, is the setup stuff for "tsk->hardirqs_enabled" > > > perhaps off a bit? > > > > hm. I cannot see the source of the bug at the moment, but here's my > > analysis so far: > > > > the last event that irqtrace got was #69, and that was a 'hardirqs on' > > in syscall_exit_work. After that we did a 'hardirqs off' without > > properly tracking that via irqtrace. Next time we got an irqtrace event > > (event 70) the assert caught up with us and turned off lockdep and > > backed out of that function. This was in: > > > > > [ 116.754957] [] check_flags+0x95/0x143 > > > [ 116.754967] [] lock_acquire+0x29/0x82 > > > [ 116.754977] [] _spin_lock+0x35/0x42 > > > [ 116.754990] [] refrigerator+0x14/0xc6 > > > [ 116.755002] [] get_signal_to_deliver+0x33/0x397 > > > [ 116.755016] [] do_notify_resume+0x94/0x6ed > > > [ 116.755029] [] work_notifysig+0x13/0x1a > > > > isnt the refrigerator() suspend related? Perhaps suspend disables irqs > > somewhere that we forgot to track? > > refrigerator is suspend related, but I do not think it does any > interrupt magic. We do magic later in hibernation process. > > This is in kernel/power/process.c, we have spinlock_irqsave there, but > that's pretty much it AFAICT. That's correct. We don't manipulate IRQs directly in the freezer. Greetings, Rafael -- "Premature optimization is the root of all evil." - Donald Knuth - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/