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

[Manoj Iyer]

I did a comparison between 3 kernels.
* with no XX_DEBUG
* with current XX_DEBUG (stock lucid)
* with extra XX_DEBUG I listed earlier (see history below)

The difference between the 3 kernels from a usage perspective is the same, 
ie
* file copy, tar, move, rm are approximately the same.
* desktop experience, ie open close firefox, openoffice etc similar
* suspend resume times nothing noticeably different.
* reboot, shutdown times are quiet similar.

My understanding from the way ACPI_DEBUG worked is that most the debug 
messages, levels and layers could be controlled from sysfs, thus limiting 
what and when to send messages to dmesg. But I found out that with extra 
options turned on there is a lot more extra stuff sent to dmesg. I think 
that is ugly, and its bad to turn on these options permanently in the 
kernel we ship.

I have a test kernel (i386 & amd64), that you can try if you are 
interested in extra debug capability. It is based on lucid 2.6.32-22 #34.

http://people.canonical.com/~manjo/lucid-extradebug/


Cheers
--- manjo

On Thu, 3 Jun 2010, manoj.iyer at canonical.com wrote:

>
> 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_SND_DEBUG_VERBOSE=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
>> 
>