[PATCH] PM: Remove WARN_ON from device_pm_add

[PATCH] PM: Remove WARN_ON from device_pm_add

[Rafael J. Wysocki]

PM: Remove WARN_ON from device_pm_add

Fix message in device_pm_add() saying that the device will not be
added to dpm_list, although in fact the device is going to be added
to the list regardless of the ordering violation.

Remove the WARN_ON(true) triggered in that situation, because it is
hit by USB very often and spams the users' logs.

This patch fixes bug #11263

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 drivers/base/power/main.c |    6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

Index: linux-2.6/drivers/base/power/main.c
===================================================================
--- linux-2.6.orig/drivers/base/power/main.c
+++ linux-2.6/drivers/base/power/main.c
@@ -74,11 +74,9 @@ void device_pm_add(struct device *dev)
 		 kobject_name(&dev->kobj));
 	mutex_lock(&dpm_list_mtx);
 	if (dev->parent) {
-		if (dev->parent->power.status >= DPM_SUSPENDING) {
-			dev_warn(dev, "parent %s is sleeping, will not add\n",
+		if (dev->parent->power.status >= DPM_SUSPENDING)
+			dev_warn(dev, "parent %s should not be sleeping\n",
 				dev->parent->bus_id);
-			WARN_ON(true);
-		}
 	} else if (transition_started) {
 		/*
 		 * We refuse to register parentless devices while a PM

Re: [PATCH] PM: Remove WARN_ON from device_pm_add

[Adrian Bunk]

On Sat, Aug 09, 2008 at 01:05:13AM +0200, Rafael J. Wysocki wrote:
> PM: Remove WARN_ON from device_pm_add
> 
> Fix message in device_pm_add() saying that the device will not be
> added to dpm_list, although in fact the device is going to be added
> to the list regardless of the ordering violation.
> 
> Remove the WARN_ON(true) triggered in that situation, because it is
> hit by USB very often and spams the users' logs.
> 
> This patch fixes bug #11263

Michael Tsirkin said in #11284 (which is marked as a duplicate of #11263):

<--  snip  -->

> What exactly is this instability?

X often crashes on resume, sometimes ACPI seems to stop working
after resume. I am trying to figure exact way to reproduce first,
or get some relevant logs, then I'll report.

> Does 2.6.26 work fine?

yes

<--  snip  -->


Is this a separate regression or did the WARN_ON different from the 
first assumption indicate a functional regression?


> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
> ---
>  drivers/base/power/main.c |    6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> Index: linux-2.6/drivers/base/power/main.c
> ===================================================================
> --- linux-2.6.orig/drivers/base/power/main.c
> +++ linux-2.6/drivers/base/power/main.c
> @@ -74,11 +74,9 @@ void device_pm_add(struct device *dev)
>  		 kobject_name(&dev->kobj));
>  	mutex_lock(&dpm_list_mtx);
>  	if (dev->parent) {
> -		if (dev->parent->power.status >= DPM_SUSPENDING) {
> -			dev_warn(dev, "parent %s is sleeping, will not add\n",
> +		if (dev->parent->power.status >= DPM_SUSPENDING)
> +			dev_warn(dev, "parent %s should not be sleeping\n",
>  				dev->parent->bus_id);
> -			WARN_ON(true);
> -		}
>  	} else if (transition_started) {
>  		/*
>  		 * We refuse to register parentless devices while a PM

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] PM: Remove WARN_ON from device_pm_add

[Rafael J. Wysocki]

On Tuesday, 12 of August 2008, Adrian Bunk wrote:
> On Sat, Aug 09, 2008 at 01:05:13AM +0200, Rafael J. Wysocki wrote:
> > PM: Remove WARN_ON from device_pm_add
> > 
> > Fix message in device_pm_add() saying that the device will not be
> > added to dpm_list, although in fact the device is going to be added
> > to the list regardless of the ordering violation.
> > 
> > Remove the WARN_ON(true) triggered in that situation, because it is
> > hit by USB very often and spams the users' logs.
> > 
> > This patch fixes bug #11263
> 
> Michael Tsirkin said in #11284 (which is marked as a duplicate of #11263):
> 
> <--  snip  -->
> 
> > What exactly is this instability?
> 
> X often crashes on resume, sometimes ACPI seems to stop working
> after resume. I am trying to figure exact way to reproduce first,
> or get some relevant logs, then I'll report.
> 
> > Does 2.6.26 work fine?
> 
> yes
> 
> <--  snip  -->
> 
> 
> Is this a separate regression or did the WARN_ON different from the 
> first assumption indicate a functional regression?

No, it doesn't indicate a functional regression.

In 2.6.26 the WARN_ON() was artificially silenced by USB, but that stopped
working after the PM core had changed in 2.6.27-rc.

Thanks,
Rafael