[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.0911091622590.2858-100000@iolanthe.rowland.org>
Date: Mon, 9 Nov 2009 16:24:55 -0500 (EST)
From: Alan Stern <stern@...land.harvard.edu>
To: "Rafael J. Wysocki" <rjw@...k.pl>
cc: Thomas Gleixner <tglx@...utronix.de>,
Mike Galbraith <efault@....de>, Greg KH <gregkh@...e.de>,
LKML <linux-kernel@...r.kernel.org>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
pm list <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] Help needed: Resume problems in 2.6.32-rc, perhaps
related to preempt_count leakage in keventd
On Mon, 9 Nov 2009, Rafael J. Wysocki wrote:
> On Monday 09 November 2009, Alan Stern wrote:
> > On Mon, 9 Nov 2009, Rafael J. Wysocki wrote:
> >
> > > Still, RIP always points to list_del_init(cwq->worklist.next); in
> > > run_workqueue().
> >
> > Use a big hammer: Create a new global variable, set it to 1 while
> > resuming and back to 0 after the tasks have been thawed. While the
> > variable is nonzero, print in the log the list pointers in
> > cwq->worklist just before executing the list_del_init(). Maybe also
> > print some other interesting information about cwq.
>
> I've just sent a message containing full call trace.
>
> It shows the problem is a general protection fault that happens _after_ we've
> thawed tasks.
Okay, so set the variable to 1 when the tasks are thawed and back to 0
a second later. The point is that you _can_ get more detailed
information about the bad data values without flooding the system log.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists