Project

General

Profile

Feature #1783

ACPI CA should be less verbose in release builds

Added by Yuri Pankov almost 9 years ago. Updated about 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
kernel
Start date:
2011-11-16
Due date:
% Done:

0%

Estimated time:
Difficulty:
Bite-size
Tags:
Gerrit CR:

Description

Now we are printing the following on every access to failing method (even on non-debug builds!) - for me it's 2x the message every 30 seconds (probably the gnome applets querying for battery status and temperature info):

Nov 16 01:03:48 deneb acpica: [ID 899349 kern.notice] ACPI Exception: AE_ERROR, Returned by Handler for [EmbeddedControl] (20110527/evregion-521)
Nov 16 01:03:48 deneb acpica: [ID 100000 kern.notice]
Nov 16 01:03:48 deneb acpica: [ID 296497 kern.notice] **** Exception AE_ERROR during execution of method [\\_SB_.ACAD._PSR] (Node ffffff025f16cd80)
Nov 16 01:03:48 deneb acpica: [ID 100000 kern.notice]
Nov 16 01:03:48 deneb acpica: [ID 652514 kern.notice] Method Execution Stack:
Nov 16 01:03:48 deneb acpica: [ID 536025 kern.notice]     Method [_PSR] executing: ^^PCI0.LPCB.EC0.SW2S
Nov 16 01:03:48 deneb acpica: [ID 100000 kern.notice]
Nov 16 01:03:48 deneb acpica: [ID 325098 kern.notice] Local Variables for method [_PSR]:
Nov 16 01:03:48 deneb acpica: [ID 168412 kern.notice]     Local0: 0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 170460 kern.notice]     Local1: 0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 172508 kern.notice]     Local2: 0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 174556 kern.notice]     Local3: 0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 176604 kern.notice]     Local4: 0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 178652 kern.notice]     Local5: 0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 180700 kern.notice]     Local6: 0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 182748 kern.notice]     Local7: 0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 100000 kern.notice]
Nov 16 01:03:48 deneb acpica: [ID 404092 kern.notice] Arguments for Method [_PSR]:  (0 arguments defined, max concurrency = 0)
Nov 16 01:03:48 deneb acpica: [ID 975559 kern.notice]     Arg0:   0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 975561 kern.notice]     Arg1:   0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 975563 kern.notice]     Arg2:   0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 975565 kern.notice]     Arg3:   0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 975567 kern.notice]     Arg4:   0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 975569 kern.notice]     Arg5:   0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 975571 kern.notice]     Arg6:   0 <Null Object>
Nov 16 01:03:48 deneb acpica: [ID 100000 kern.notice]
Nov 16 01:03:48 deneb acpica: [ID 327761 kern.notice] ACPI Error: Method parse/execution failed [\\_SB_.ACAD._PSR] (Node ffffff025f16cd80), AE_ERROR (20110527/psparse-560)

What we could do - do NOT enable ACPI_DISASSEMBLER by default (most of lines above come from it), leave comment in uts/intel/acpica/Makefile on how to enable it back (it shouldn't really be needed if you aren't going to debug it), and make ACPICA really silent on release builds, i.e.:

Nov 16 17:07:05 deneb acpica: [ID 899349 kern.notice] ACPI Exception: AE_ERROR, Returned by Handler for [EmbeddedControl] (20110527/evregion-521)
Nov 16 17:07:05 deneb acpica: [ID 804409 kern.notice] ACPI Error: Method parse/execution failed [\\_SB_.ACAD._PSR] (Node ffffff025f2a6d80), AE_ERROR (20110527/psparse-560)

printed in debug builds (it's more than enough to starting looking into what's wrong), no error messages on release builds, and full output when adding -DACPI_DEBUG_OUTPUT -DACPI_DISASSEMBLER to CFLAGS (as the comment in uts/intel/acpica/Makefile says).

History

#1

Updated by Richard Elling almost 9 years ago

Verboseness doesn't kill. Lack of verboseness kills.

I'd much rather see the root cause corrected than a weak attempt to kill the messenger.

#2

Updated by Rich Lowe almost 9 years ago

Sure, but logging it twice every 30 seconds is overkill.
What I'd want is to see it logged once, and then not again (perhaps, in release builds, logged once, tersely, and then not again).

Gordon was looking for the root cause in this specific case, and that's why we'd want it to remain logged in DEBUG builds, and ideally logged more gracefully in release builds, but in some cases -- especially with ACPI -- the root cause is "Your bios was written by cretins", and thus the fix is at their discretion. Filling your disk with spew isn't going to help anyone.

#3

Updated by Yuri Pankov almost 9 years ago

Ok, let's leave ACPI_DEBUG_OUTPUT + ACPI_DISASSEMBLER for debug builds, but remove them for release ones.

Rich, I don't think that it's possible to somehow limit the messages number in my case - they are printed on every access to the failing objects (so the fix could well be "stop querying for status")...

#4

Updated by Yuri Pankov about 7 years ago

  • Subject changed from ACPI could be less verbose by default to ACPI CA should be less verbose in release builds
  • Status changed from New to In Progress
  • Assignee set to Yuri Pankov
  • % Done changed from 0 to 50
  • Difficulty changed from Medium to Bite-size
#5

Updated by Yuri Pankov about 3 years ago

  • Status changed from In Progress to Closed
  • Assignee deleted (Yuri Pankov)
  • % Done changed from 50 to 0
  • Tags deleted (acpi acpica)

Also available in: Atom PDF