[RFC] debug kernel for Lucid/Maverick/Mainline?

manoj.iyer at canonical.com manoj.iyer at canonical.com
Thu Jun 3 17:01:52 UTC 2010


Here are some of the interesting DEBUG options that I think might be worth 
turning on in a debug kernel. I don't know if it a good idea to have them 
permanently turned on.

CONFIG_ACPI_DEBUG=y
CONFIG_ACPI_DEBUG_FUNC_TRACE=y
CONFIG_PCI_DEBUG=y
CONFIG_POWER_SUPPLY_DEBUG=y
CONFIG_SND_VERBOSE_PRINTK=y
CONFIG_SND_DEBUG=y
CONFIG_USB_DEBUG=y
CONFIG_RTC_DEBUG=y
CONFIG_EXT4_DEBUG=y

There is a bunch of them under
#
# Kernel hacking
#
Some of the more interesting ones here are:
CONFIG_DEBUG_SPINLOCK
CONFIG_DEBUG_MUTEXES
CONFIG_DEBUG_SPINLOCK_SLEEP
CONFIG_DEBUG_VM
CONFIG_DEBUG_STACKOVERFLOW
CONFIG_DEBUG_STACK_USAGE

Cheers
--- manjo

On Thu, 3 Jun 2010, Andy Whitcroft wrote:

> On Wed, Jun 02, 2010 at 05:17:11PM -0500, Manoj Iyer wrote:
>
>> I propose we build a kernel with certain XX_DEBUG turned on for Lucid,
>> Maverick and Mainline. The benefits of having it are:
>>
>> * we can point people at this debug kernel give them instructions on how
>> to control debug prints though sysfs and get more data that might help
>> debug problems. Certainly in the case where debugging kernel across
>> suspend/resume etc.
>
> Which debug options do you have in mind?
>
>> * We could use this kernel in our alpha/beta compatibility testing ISO, we
>> could collect more debug information for each test. For example turn on
>> debug before suspend and turn off after resume, if suspend/resume had
>> issues, took long times etc we might be able to gather bit more
>> information as to why.
>
> One issue we introduce here is that by turning on the DEBUG_XX options
> which we are saying are not suitable for production use we change the
> kernel we are testing away from that which we want to work, we are not
> testing the same beast any more which effectivly lowers the quality of
> the results as a test of the original kernel.
>
>> * I think mainline kernel builds should have config debug turned on by
>> default, since this is "try & test this" kernel, what is the harm in
>> having a slightly bloated kernel?
>
> Possibly, again which options are you itching to have.
>
> -apw
>




More information about the kernel-team mailing list