Bug 2398 - RFE: ACPI debug enhancements
RFE: ACPI debug enhancements
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: Other
i386 Linux
: P2 normal
Assigned To: Zhu Yi
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-30 13:30 UTC by Len Brown
Modified: 2004-11-03 18:56 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.4, 2.6
Tree: Mainline
Regression: ---


Attachments
ACPI debug enhancement patch. (7.37 KB, patch)
2004-08-04 22:04 UTC, Zhu Yi
Details | Diff
revised version (8.16 KB, patch)
2004-08-06 02:20 UTC, Zhu Yi
Details | Diff

Description Len Brown 2004-03-30 13:31:00 UTC
What we need: 
1. less expensive build-time option than CONFIG_ACPI_DEBUG 
    that distros can ship enabled by default. 
2. ability to set acpi debug flags on boot cmdline 
    particularly to debug boot failures 
3. better /proc support ala ipw2100 
    for better control over run-time debugging. 
 
certainly we need to do away with the current hard-coded invocation of 
acpi_set_debug() from acpi_init().
Comment 1 Andi Kleen 2004-07-23 11:11:45 UTC
  
There should be a new command line option:  
  
acpi_debug=layer1:debuglevel,layer2:debuglevel  
  
There should be some way to enable/disable function call tracing for a layer. 
The default for this should be off unless explicitely enabled. 
 
When ACPI_DEBUG is compiled in there should be no more output than without  
it, all additional output should be keyed on the command line.  
  
ACPI_DEBUG should be split into multiple options: an ACPI_LEAN_DEBUG  
that only enables error/warning output and a ACPI_TRACE_DEBUG that  
compiles in all the function tracing. This would enable to compile  
the important debug output code into the production kernel without   
undue binary size overhead.  
  
Comment 2 Zhu Yi 2004-08-04 22:04:51 UTC
Created attachment 3471 [details]
ACPI debug enhancement patch.


Andi, I also tried your CONFIG_ACPI_LEAN_DEBUG suggestion. Base on my
investigation, the "trace debug" takes up 1/3 of the total debug information,
about 20k. Since it is not the major part of the debug info, I didn't implement
it.
Comment 3 Andi Kleen 2004-08-05 05:59:52 UTC
Sorry didn't see the patch earlier because I wasn't in cc.

Did you investigate where the majority of the debug overhead comes from?  A bit
more light weight debugging would be still nice.

The patch looks good for a start. Can you merge it into mainline? 

Comment 4 Andi Kleen 2004-08-05 06:06:04 UTC
A small comment - it would be nicer if the individual levels were ascii
strings separated by comma instead of numbers. Could you please change that?
Thanks.
Comment 5 Zhu Yi 2004-08-06 02:03:41 UTC
The ACPI_DEBUG_PRINT macro is called 780 times, most of which use ERROR and 
INFO severity. TRACE related macros are called 600 times, DUMP macros are rare 
comparing with first two.

I assume the ascii requirement is for boot cmdline, because the /proc 
interface will print more meaningful debug levels. There are now 30 
debug_levels, it could be a long string if one wants to enable many levels 
with ascii. Right?
Comment 6 Zhu Yi 2004-08-06 02:20:03 UTC
Created attachment 3478 [details]
revised version

add ACPI_ALL_DRIVERS support for debug_layer
Comment 7 Len Brown 2004-08-06 11:15:35 UTC
i'm okay with having numbers on the command line,
particularly in light of how many bits we have --
we'd have to invent a new language just to describe
them all.  Also, these are debug flags, which end-users
are going to use only under the guidance of some technical
person who can tell them what flags to type in.
Ditto for the /proc/ interface.
Comment 8 Len Brown 2004-11-03 18:56:07 UTC
shipped in 2.6.9
closing

Note You need to log in before you can comment on or make changes to this bug.