Re: [GIT PULL] ACPI and power management updates for 3.19-rc1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday, December 12, 2014 03:42:07 PM Rafael J. Wysocki wrote:
> On Thursday, December 11, 2014 07:59:20 PM Linus Torvalds wrote:
> > On Mon, Dec 8, 2014 at 4:21 PM, Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
> > >
> > > Also the ACPI core is now going to support the _DEP configuration
> > > information in a limited way.
> > 
> > Hmm. That seems to be the cause of this annoying new message:
> > 
> >     ...
> >     ACPI: Using IOAPIC for interrupt routing
> >     PCI: Using host bridge windows from ACPI; if necessary, use
> > "pci=nocrs" and report a bug
> >     ACPI: [Package] has zero elements (ffff88040ccdb200)
> >     acpi LNXCPU:00: Failed to evaluate _DEP.
> >     ACPI: [Package] has zero elements (ffff88040ccdb200)
> >     acpi LNXCPU:01: Failed to evaluate _DEP.
> >     ACPI: [Package] has zero elements (ffff88040ccdb200)
> >     acpi LNXCPU:02: Failed to evaluate _DEP.
> >     ACPI: [Package] has zero elements (ffff88040ccdb200)
> >     acpi LNXCPU:03: Failed to evaluate _DEP.
> >     ACPI: [Package] has zero elements (ffff88040ccdb200)
> >     acpi LNXCPU:04: Failed to evaluate _DEP.
> >     ACPI: [Package] has zero elements (ffff88040ccdb200)
> >     acpi LNXCPU:05: Failed to evaluate _DEP.
> >     ACPI: [Package] has zero elements (ffff88040ccdb200)
> >     acpi LNXCPU:06: Failed to evaluate _DEP.
> >     ACPI: [Package] has zero elements (ffff88040ccdb200)
> >     acpi LNXCPU:07: Failed to evaluate _DEP.
> >     ACPI: [Package] has zero elements (ffff88040ccdb840)
> >     acpi device:27: Failed to evaluate _DEP.
> >     ACPI: [Package] has zero elements (ffff88040ccdb840)
> >     acpi device:3f: Failed to evaluate _DEP.
> >     ACPI: [Package] has zero elements (ffff88040ccdb8c0)
> >     acpi LNXVIDEO:00: Failed to evaluate _DEP.
> >     ACPI: Power Resource [FN00] (off)
> >     ...
> > 
> > which doesn't seem to hinder anything from working, but is extremely
> > annoying because it's printed out as some super-important "KERN_ERR
> > message of Doom!"
> > 
> > I don't see why incomplete ACPI tables would *ever* be "KERN_ERR"
> > level messages, but I particularly don't see it when it seems to be
> > our own meaningless fake entries.
> 
> Right the KERN_ERR level in there is silly.  Overlooked in review, sorry
> about that.  The patch below should take care of it.
> 
> Some of the messages you're seeing are from acpi_evaluate_reference(),
> though, and are not really useful too.  I'll cut a separate patch for
> these.

This:

---
From: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
Subject: ACPI / utils: Drop error messages from acpi_evaluate_reference()

Some of the error messages printed by acpi_evaluate_reference()
with the KERN_ERR priority should really be debug messages, but then
they would be redundant, because acpi_util_eval_error() is called
too at the same spots (except for one).

Drop the kernel messages from there entirely and leave the
acpi_util_eval_error() to take care of the debug printing.  In one case,
replace the kernel message with a call to acpi_util_eval_error().

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
---
 drivers/acpi/utils.c |   12 +-----------
 1 file changed, 1 insertion(+), 11 deletions(-)

Index: linux-pm/drivers/acpi/utils.c
===================================================================
--- linux-pm.orig/drivers/acpi/utils.c
+++ linux-pm/drivers/acpi/utils.c
@@ -346,22 +346,16 @@ acpi_evaluate_reference(acpi_handle hand
 	package = buffer.pointer;
 
 	if ((buffer.length == 0) || !package) {
-		printk(KERN_ERR PREFIX "No return object (len %X ptr %p)\n",
-			    (unsigned)buffer.length, package);
 		status = AE_BAD_DATA;
 		acpi_util_eval_error(handle, pathname, status);
 		goto end;
 	}
 	if (package->type != ACPI_TYPE_PACKAGE) {
-		printk(KERN_ERR PREFIX "Expecting a [Package], found type %X\n",
-			    package->type);
 		status = AE_BAD_DATA;
 		acpi_util_eval_error(handle, pathname, status);
 		goto end;
 	}
 	if (!package->package.count) {
-		printk(KERN_ERR PREFIX "[Package] has zero elements (%p)\n",
-			    package);
 		status = AE_BAD_DATA;
 		acpi_util_eval_error(handle, pathname, status);
 		goto end;
@@ -380,17 +374,13 @@ acpi_evaluate_reference(acpi_handle hand
 
 		if (element->type != ACPI_TYPE_LOCAL_REFERENCE) {
 			status = AE_BAD_DATA;
-			printk(KERN_ERR PREFIX
-				    "Expecting a [Reference] package element, found type %X\n",
-				    element->type);
 			acpi_util_eval_error(handle, pathname, status);
 			break;
 		}
 
 		if (!element->reference.handle) {
-			printk(KERN_WARNING PREFIX "Invalid reference in"
-			       " package %s\n", pathname);
 			status = AE_NULL_ENTRY;
+			acpi_util_eval_error(handle, pathname, status);
 			break;
 		}
 		/* Get the  acpi_handle. */

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux