mmotm 2010-07-19 - e1000e vs. pm_qos_update_request issues
in [Kernel]
|
Prev: [PATCH 6/7] drm: use workqueue instead of slow-work
Next: [PATCH 5/7] gfs2: use workqueue instead of slow-work
From: Valdis.Kletnieks on 20 Jul 2010 16:40 On Mon, 19 Jul 2010 16:38:09 PDT, akpm(a)linux-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.
From: Andrew Morton on 20 Jul 2010 17:10 On Tue, 20 Jul 2010 16:35:25 -0400 Valdis.Kletnieks(a)vt.edu wrote: > On Mon, 19 Jul 2010 16:38:09 PDT, akpm(a)linux-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(a)suse.de> : AuthorDate: Mon Jul 5 22:53:06 2010 +0200 : Commit: Rafael J. Wysocki <rjw(a)sisk.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*. So one must assume that the people who stuck this thing in the tree have volunteered to fix e1000e. Let's cc 'em. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: mark gross on 21 Jul 2010 18:10 On Tue, Jul 20, 2010 at 02:07:51PM -0700, Andrew Morton wrote: > On Tue, 20 Jul 2010 16:35:25 -0400 > Valdis.Kletnieks(a)vt.edu wrote: > > > On Mon, 19 Jul 2010 16:38:09 PDT, akpm(a)linux-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(a)suse.de> > : AuthorDate: Mon Jul 5 22:53:06 2010 +0200 > : Commit: Rafael J. Wysocki <rjw(a)sisk.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 linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Valdis.Kletnieks on 22 Jul 2010 00:10 On Wed, 21 Jul 2010 09:12:00 +0200, Florian Mickler said: > Attached patch moves the registering from e1000_up to e1000_open and > the unregistering from e1000_down to e1000_close. > It is only compile-tested as I don't have the hardware. My laptop has the hardware, so I tested it - system does indeed boot without whinging about this issue. Feel free to stick in a: Tested-by: Valdis Kletnieks <valdis.kletnieks(a)vt.edu> Thanks for the fast fix. :) > From 693c71b911ff0845c872261d5704a1d40960722d Mon Sep 17 00:00:00 2001 > From: Florian Mickler <florian(a)mickler.org> > Date: Wed, 21 Jul 2010 08:44:21 +0200 > Subject: [PATCH] e1000e: register pm_qos request on hardware activation > > The pm_qos_add_request call has to register the pm_qos request with the pm_qos > susbsystem before first use of the pm_qos request via > pm_qos_update_request. > > As pm_qos changed to use plists there is no benefit in registering and > unregistering the pm_qos request on ifup/ifdown and thus we move the > registering into e1000_open and the unregistering in e1000_close.
From: Rafael J. Wysocki on 22 Jul 2010 18:10
On Thursday, July 22, 2010, Valdis.Kletnieks(a)vt.edu wrote: > On Wed, 21 Jul 2010 09:12:00 +0200, Florian Mickler said: > > > Attached patch moves the registering from e1000_up to e1000_open and > > the unregistering from e1000_down to e1000_close. > > It is only compile-tested as I don't have the hardware. > > My laptop has the hardware, so I tested it - system does indeed boot > without whinging about this issue. Feel free to stick in a: > > Tested-by: Valdis Kletnieks <valdis.kletnieks(a)vt.edu> > > Thanks for the fast fix. :) I'm going to add the patch to the suspend-2.6 tree. Any objections? > > From 693c71b911ff0845c872261d5704a1d40960722d Mon Sep 17 00:00:00 2001 > > From: Florian Mickler <florian(a)mickler.org> > > Date: Wed, 21 Jul 2010 08:44:21 +0200 > > Subject: [PATCH] e1000e: register pm_qos request on hardware activation > > > > The pm_qos_add_request call has to register the pm_qos request with the pm_qos > > susbsystem before first use of the pm_qos request via > > pm_qos_update_request. > > > > As pm_qos changed to use plists there is no benefit in registering and > > unregistering the pm_qos request on ifup/ifdown and thus we move the > > registering into e1000_open and the unregistering in e1000_close. Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |