[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100721220926.GA2610@gvim.org>
Date: Wed, 21 Jul 2010 15:09:26 -0700
From: mark gross <markgross@...gnar.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Valdis.Kletnieks@...edu, Thomas Gleixner <tglx@...utronix.de>,
"David S. Miller" <davem@...emloft.net>,
linux-kernel@...r.kernel.org, e1000-devel@...ts.sourceforge.net,
netdev@...r.kernel.org,
James Bottomley <James.Bottomley@...senPartnership.com>,
"Rafael J. Wysocki" <rjw@...k.pl>,
mark gross <markgross@...gnar.org>
Subject: Re: mmotm 2010-07-19 - e1000e vs. pm_qos_update_request issues
On Tue, Jul 20, 2010 at 02:07:51PM -0700, Andrew Morton wrote:
> On Tue, 20 Jul 2010 16:35:25 -0400
> Valdis.Kletnieks@...edu wrote:
>
> > On Mon, 19 Jul 2010 16:38:09 PDT, akpm@...ux-foundation.org said:
> > > The mm-of-the-moment snapshot 2010-07-19-16-37 has been uploaded to
> > >
> > > http://userweb.kernel.org/~akpm/mmotm/
> >
> > Throws a warning at boot:
> >
> > [ 1.786060] WARNING: at kernel/pm_qos_params.c:264 pm_qos_update_request+0x28/0x54()
> > [ 1.786088] Hardware name: Latitude E6500
> > [ 1.787045] pm_qos_update_request() called for unknown object
> > [ 1.787966] Modules linked in:
> > [ 1.788940] Pid: 1, comm: swapper Not tainted 2.6.35-rc5-mmotm0719 #1
> > [ 1.790035] Call Trace:
> > [ 1.791121] [<ffffffff81037335>] warn_slowpath_common+0x80/0x98
> > [ 1.792205] [<ffffffff810373e1>] warn_slowpath_fmt+0x41/0x43
> > [ 1.793279] [<ffffffff81057c14>] pm_qos_update_request+0x28/0x54
> > [ 1.794347] [<ffffffff8134889e>] e1000_configure+0x421/0x459
> > [ 1.795393] [<ffffffff8134afbd>] e1000_open+0xbd/0x37c
> > [ 1.796436] [<ffffffff8105743a>] ? raw_notifier_call_chain+0xf/0x11
> > [ 1.797491] [<ffffffff8145f948>] __dev_open+0xae/0xe2
> > [ 1.798547] [<ffffffff8145f997>] dev_open+0x1b/0x49
> > [ 1.799612] [<ffffffff8146e36e>] netpoll_setup+0x84/0x259
> > [ 1.800685] [<ffffffff81b5037c>] init_netconsole+0xbc/0x21f
> > [ 1.801744] [<ffffffff81b5026c>] ? sir_wq_init+0x0/0x35
> > [ 1.802793] [<ffffffff81b502c0>] ? init_netconsole+0x0/0x21f
> > [ 1.803845] [<ffffffff810002ff>] do_one_initcall+0x7a/0x12f
> > [ 1.804885] [<ffffffff81b2ccae>] kernel_init+0x138/0x1c2
> > [ 1.805915] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
> > [ 1.806937] [<ffffffff81590e00>] ? restore_args+0x0/0x30
> > [ 1.807955] [<ffffffff81b2cb76>] ? kernel_init+0x0/0x1c2
> > [ 1.808958] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
> > [ 1.809958] ---[ end trace 84b562a00a60539e ]---
> >
> > Looks like a repeat of something I reported against -mmotm 2010-05-11, though a
> > WARNING rather than an outright crash - the traceback is pretty much identical.
> > I have *no* idea why -rc3-mmotm0701 doesn't whinge similarly.
> >
>
> I don't recall you reporting that, sorry.
>
> The warning was added by
>
> : commit 82f682514a5df89ffb3890627eebf0897b7a84ec
> : Author: James Bottomley <James.Bottomley@...e.de>
> : AuthorDate: Mon Jul 5 22:53:06 2010 +0200
> : Commit: Rafael J. Wysocki <rjw@...k.pl>
> : CommitDate: Mon Jul 19 02:00:34 2010 +0200
> :
> : pm_qos: Get rid of the allocation in pm_qos_add_request()
>
>
> It's a pretty crappy warning too. Neither the warning nor the code
> comments provide developers with any hint as to what they have done
> wrong, nor what they must do to fix things. And the patch changelog
> doesn't mention the new warnings *at all*.
Sorry about that. Its my fault, but I thought I had stronger language
in the original warning text.
The warning is for pm_qos users that are attempting to change a request
that isn't even in the list of request. It was a silent failure in the
original code. The result of the silent fail is that the request is not
changed as assumed by the caller.
> So one must assume that the people who stuck this thing in the tree
> have volunteered to fix e1000e. Let's cc 'em.
I'll put a 1000e patch together at the airport, but I wont be able to
test it until tuesday.
--mgross
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists