If a parentless device was added during a PM transaction, developers
might want to know which device caused the troube. Hence, output the
kobject's name in this case.
Signed-off-by: Daniel Mack <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Cc: Len Brown <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Magnus Damm <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: [email protected]
---
drivers/base/power/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
index 941fcb8..9e9fe6a 100644
--- a/drivers/base/power/main.c
+++ b/drivers/base/power/main.c
@@ -98,7 +98,7 @@ void device_pm_add(struct device *dev)
* transition is in progress in order to avoid leaving them
* unhandled down the road
*/
- dev_WARN(dev, "Parentless device registered during a PM transaction\n");
+ dev_WARN(dev, "Parentless device registered during a PM transaction: %s\n", kobject_name(&dev->kobj));
}
list_add_tail(&dev->power.entry, &dpm_list);
--
1.7.1
On Fri, Jun 04, 2010 at 02:17:14PM +0200, Daniel Mack wrote:
> If a parentless device was added during a PM transaction, developers
> might want to know which device caused the troube. Hence, output the
> kobject's name in this case.
>
> Signed-off-by: Daniel Mack <[email protected]>
> Cc: Rafael J. Wysocki <[email protected]>
> Cc: Len Brown <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: Magnus Damm <[email protected]>
> Cc: Alan Stern <[email protected]>
> Cc: Randy Dunlap <[email protected]>
> Cc: [email protected]
> ---
> drivers/base/power/main.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 941fcb8..9e9fe6a 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -98,7 +98,7 @@ void device_pm_add(struct device *dev)
> * transition is in progress in order to avoid leaving them
> * unhandled down the road
> */
> - dev_WARN(dev, "Parentless device registered during a PM transaction\n");
> + dev_WARN(dev, "Parentless device registered during a PM transaction: %s\n", kobject_name(&dev->kobj));
Doesn'tthe dev_WARN call already print the name of the device? Why
print it twice?
thanks,
greg k-h
On Fri, Jun 04, 2010 at 09:45:27AM -0700, Greg KH wrote:
> On Fri, Jun 04, 2010 at 02:17:14PM +0200, Daniel Mack wrote:
> > If a parentless device was added during a PM transaction, developers
> > might want to know which device caused the troube. Hence, output the
> > kobject's name in this case.
> >
> > Signed-off-by: Daniel Mack <[email protected]>
> > Cc: Rafael J. Wysocki <[email protected]>
> > Cc: Len Brown <[email protected]>
> > Cc: Greg Kroah-Hartman <[email protected]>
> > Cc: Magnus Damm <[email protected]>
> > Cc: Alan Stern <[email protected]>
> > Cc: Randy Dunlap <[email protected]>
> > Cc: [email protected]
> > ---
> > drivers/base/power/main.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> > index 941fcb8..9e9fe6a 100644
> > --- a/drivers/base/power/main.c
> > +++ b/drivers/base/power/main.c
> > @@ -98,7 +98,7 @@ void device_pm_add(struct device *dev)
> > * transition is in progress in order to avoid leaving them
> > * unhandled down the road
> > */
> > - dev_WARN(dev, "Parentless device registered during a PM transaction\n");
> > + dev_WARN(dev, "Parentless device registered during a PM transaction: %s\n", kobject_name(&dev->kobj));
>
> Doesn'tthe dev_WARN call already print the name of the device? Why
> print it twice?
Erm, no it didn't. Should it have? This is what I saw:
[ 0.880646] Parentless device registered during a PM transaction
Daniel
On Fri, Jun 04, 2010 at 06:50:37PM +0200, Daniel Mack wrote:
> On Fri, Jun 04, 2010 at 09:45:27AM -0700, Greg KH wrote:
> > On Fri, Jun 04, 2010 at 02:17:14PM +0200, Daniel Mack wrote:
> > > If a parentless device was added during a PM transaction, developers
> > > might want to know which device caused the troube. Hence, output the
> > > kobject's name in this case.
> > >
> > > Signed-off-by: Daniel Mack <[email protected]>
> > > Cc: Rafael J. Wysocki <[email protected]>
> > > Cc: Len Brown <[email protected]>
> > > Cc: Greg Kroah-Hartman <[email protected]>
> > > Cc: Magnus Damm <[email protected]>
> > > Cc: Alan Stern <[email protected]>
> > > Cc: Randy Dunlap <[email protected]>
> > > Cc: [email protected]
> > > ---
> > > drivers/base/power/main.c | 2 +-
> > > 1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> > > index 941fcb8..9e9fe6a 100644
> > > --- a/drivers/base/power/main.c
> > > +++ b/drivers/base/power/main.c
> > > @@ -98,7 +98,7 @@ void device_pm_add(struct device *dev)
> > > * transition is in progress in order to avoid leaving them
> > > * unhandled down the road
> > > */
> > > - dev_WARN(dev, "Parentless device registered during a PM transaction\n");
> > > + dev_WARN(dev, "Parentless device registered during a PM transaction: %s\n", kobject_name(&dev->kobj));
> >
> > Doesn'tthe dev_WARN call already print the name of the device? Why
> > print it twice?
>
> Erm, no it didn't. Should it have? This is what I saw:
>
> [ 0.880646] Parentless device registered during a PM transaction
You should have gotten more information than just that single line,
right? Like a full backtrace to the driver that did the offending
thing?
It should also have had a "Device: 'device_name_here'" on the line
before this one, right?
Can you send the full output that happened here?
thanks,
greg k-h
On Fri, Jun 04, 2010 at 10:03:31AM -0700, Greg KH wrote:
> On Fri, Jun 04, 2010 at 06:50:37PM +0200, Daniel Mack wrote:
> > Erm, no it didn't. Should it have? This is what I saw:
> >
> > [ 0.880646] Parentless device registered during a PM transaction
>
> You should have gotten more information than just that single line,
> right? Like a full backtrace to the driver that did the offending
> thing?
>
> It should also have had a "Device: 'device_name_here'" on the line
> before this one, right?
>
> Can you send the full output that happened here?
Sorry, of course. Here is the trace:
[ 0.880567] ------------[ cut here ]------------
[ 0.880622] WARNING: at drivers/base/power/main.c:101 device_pm_add+0x94/0xd8()
[ 0.880639] Device: ieee80211
[ 0.880646] Parentless device registered during a PM transaction
[ 0.880660] Modules linked in: eeti_ts libertas_sdio libertas pxamci ds2760_battery w1_ds2760 wire
[ 0.880754] [<c00493a0>] (unwind_backtrace+0x0/0xec) from [<c0056db0>] (warn_slowpath_common+0x4c/0x7c)
[ 0.880793] [<c0056db0>] (warn_slowpath_common+0x4c/0x7c) from [<c0056e74>] (warn_slowpath_fmt+0x30/0x40)
[ 0.880829] [<c0056e74>] (warn_slowpath_fmt+0x30/0x40) from [<c01d4cc8>] (device_pm_add+0x94/0xd8)
[ 0.880875] [<c01d4cc8>] (device_pm_add+0x94/0xd8) from [<c01ce4dc>] (device_add+0x350/0x510)
[ 0.880910] [<c01ce4dc>] (device_add+0x350/0x510) from [<c032d500>] (wiphy_register+0x1ac/0x298)
[ 0.881033] [<c032d500>] (wiphy_register+0x1ac/0x298) from [<bf0285dc>] (lbs_cfg_register+0x54/0x9c [libertas])
[ 0.881142] [<bf0285dc>] (lbs_cfg_register+0x54/0x9c [libertas]) from [<bf02c228>] (lbs_start_card+0xa0/0x130 [libertas])
[ 0.881226] [<bf02c228>] (lbs_start_card+0xa0/0x130 [libertas]) from [<bf040b94>] (if_sdio_probe+0x84c/0x954 [libertas_sdio])
[ 0.881276] [<bf040b94>] (if_sdio_probe+0x84c/0x954 [libertas_sdio]) from [<c024fd98>] (sdio_bus_probe+0xcc/0xe8)
[ 0.881322] [<c024fd98>] (sdio_bus_probe+0xcc/0xe8) from [<c01d069c>] (driver_probe_device+0xb4/0x198)
[ 0.881359] [<c01d069c>] (driver_probe_device+0xb4/0x198) from [<c01cfc08>] (bus_for_each_drv+0x4c/0x8c)
[ 0.881396] [<c01cfc08>] (bus_for_each_drv+0x4c/0x8c) from [<c01d08d4>] (device_attach+0x54/0x70)
[ 0.881430] [<c01d08d4>] (device_attach+0x54/0x70) from [<c01cfa2c>] (bus_probe_device+0x28/0x50)
[ 0.881464] [<c01cfa2c>] (bus_probe_device+0x28/0x50) from [<c01ce510>] (device_add+0x384/0x510)
[ 0.881496] [<c01ce510>] (device_add+0x384/0x510) from [<c024fbd4>] (sdio_add_func+0x38/0x54)
[ 0.881527] [<c024fbd4>] (sdio_add_func+0x38/0x54) from [<c024f28c>] (mmc_attach_sdio+0x21c/0x2a8)
[ 0.881581] [<c024f28c>] (mmc_attach_sdio+0x21c/0x2a8) from [<c024b97c>] (mmc_rescan+0x1ec/0x28c)
[ 0.881624] [<c024b97c>] (mmc_rescan+0x1ec/0x28c) from [<c0067a60>] (worker_thread+0x168/0x1f0)
[ 0.881667] [<c0067a60>] (worker_thread+0x168/0x1f0) from [<c006abd8>] (kthread+0x78/0x80)
[ 0.881720] [<c006abd8>] (kthread+0x78/0x80) from [<c00458bc>] (kernel_thread_exit+0x0/0x8)
[ 0.881742] ---[ end trace 919a8d4b06013c07 ]---
I've been looking for the string 'phy1' in this dump and couldn't find
it. Hence I considered adding it.
But ... the backtrace should give enought of a hint, you're right.
Feel free to drop the patch then.
Thanks,
Daniel
On Fri, Jun 04, 2010 at 07:07:41PM +0200, Daniel Mack wrote:
> On Fri, Jun 04, 2010 at 10:03:31AM -0700, Greg KH wrote:
> > On Fri, Jun 04, 2010 at 06:50:37PM +0200, Daniel Mack wrote:
> > > Erm, no it didn't. Should it have? This is what I saw:
> > >
> > > [ 0.880646] Parentless device registered during a PM transaction
> >
> > You should have gotten more information than just that single line,
> > right? Like a full backtrace to the driver that did the offending
> > thing?
> >
> > It should also have had a "Device: 'device_name_here'" on the line
> > before this one, right?
> >
> > Can you send the full output that happened here?
>
> Sorry, of course. Here is the trace:
>
> [ 0.880567] ------------[ cut here ]------------
> [ 0.880622] WARNING: at drivers/base/power/main.c:101 device_pm_add+0x94/0xd8()
> [ 0.880639] Device: ieee80211
Here's the device name.
> [ 0.880646] Parentless device registered during a PM transaction
> [ 0.880660] Modules linked in: eeti_ts libertas_sdio libertas pxamci ds2760_battery w1_ds2760 wire
> [ 0.880754] [<c00493a0>] (unwind_backtrace+0x0/0xec) from [<c0056db0>] (warn_slowpath_common+0x4c/0x7c)
> [ 0.880793] [<c0056db0>] (warn_slowpath_common+0x4c/0x7c) from [<c0056e74>] (warn_slowpath_fmt+0x30/0x40)
> [ 0.880829] [<c0056e74>] (warn_slowpath_fmt+0x30/0x40) from [<c01d4cc8>] (device_pm_add+0x94/0xd8)
> [ 0.880875] [<c01d4cc8>] (device_pm_add+0x94/0xd8) from [<c01ce4dc>] (device_add+0x350/0x510)
> [ 0.880910] [<c01ce4dc>] (device_add+0x350/0x510) from [<c032d500>] (wiphy_register+0x1ac/0x298)
> [ 0.881033] [<c032d500>] (wiphy_register+0x1ac/0x298) from [<bf0285dc>] (lbs_cfg_register+0x54/0x9c [libertas])
> [ 0.881142] [<bf0285dc>] (lbs_cfg_register+0x54/0x9c [libertas]) from [<bf02c228>] (lbs_start_card+0xa0/0x130 [libertas])
> [ 0.881226] [<bf02c228>] (lbs_start_card+0xa0/0x130 [libertas]) from [<bf040b94>] (if_sdio_probe+0x84c/0x954 [libertas_sdio])
> [ 0.881276] [<bf040b94>] (if_sdio_probe+0x84c/0x954 [libertas_sdio]) from [<c024fd98>] (sdio_bus_probe+0xcc/0xe8)
> [ 0.881322] [<c024fd98>] (sdio_bus_probe+0xcc/0xe8) from [<c01d069c>] (driver_probe_device+0xb4/0x198)
> [ 0.881359] [<c01d069c>] (driver_probe_device+0xb4/0x198) from [<c01cfc08>] (bus_for_each_drv+0x4c/0x8c)
> [ 0.881396] [<c01cfc08>] (bus_for_each_drv+0x4c/0x8c) from [<c01d08d4>] (device_attach+0x54/0x70)
> [ 0.881430] [<c01d08d4>] (device_attach+0x54/0x70) from [<c01cfa2c>] (bus_probe_device+0x28/0x50)
> [ 0.881464] [<c01cfa2c>] (bus_probe_device+0x28/0x50) from [<c01ce510>] (device_add+0x384/0x510)
> [ 0.881496] [<c01ce510>] (device_add+0x384/0x510) from [<c024fbd4>] (sdio_add_func+0x38/0x54)
> [ 0.881527] [<c024fbd4>] (sdio_add_func+0x38/0x54) from [<c024f28c>] (mmc_attach_sdio+0x21c/0x2a8)
> [ 0.881581] [<c024f28c>] (mmc_attach_sdio+0x21c/0x2a8) from [<c024b97c>] (mmc_rescan+0x1ec/0x28c)
> [ 0.881624] [<c024b97c>] (mmc_rescan+0x1ec/0x28c) from [<c0067a60>] (worker_thread+0x168/0x1f0)
> [ 0.881667] [<c0067a60>] (worker_thread+0x168/0x1f0) from [<c006abd8>] (kthread+0x78/0x80)
> [ 0.881720] [<c006abd8>] (kthread+0x78/0x80) from [<c00458bc>] (kernel_thread_exit+0x0/0x8)
> [ 0.881742] ---[ end trace 919a8d4b06013c07 ]---
>
> I've been looking for the string 'phy1' in this dump and couldn't find
> it. Hence I considered adding it.
>
> But ... the backtrace should give enought of a hint, you're right.
>
> Feel free to drop the patch then.
Consider it dropped :)
thanks,
greg k-h