FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Kernel Team

 
 
LinkBack Thread Tools
 
Old 06-02-2010, 10:17 PM
Manoj Iyer
 
Default debug kernel for Lucid/Maverick/Mainline?

Hi all,

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.

* 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.

* 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?

Any thoughts?

Cheers
--- manjo

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-03-2010, 06:57 AM
Andy Whitcroft
 
Default debug kernel for Lucid/Maverick/Mainline?

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

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-03-2010, 05:01 PM
 
Default debug kernel for Lucid/Maverick/Mainline?

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
>

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-03-2010, 09:23 PM
Manoj Iyer
 
Default debug kernel for Lucid/Maverick/Mainline?

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@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
>>
>

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 
Old 06-03-2010, 09:44 PM
Daniel J Blueman
 
Default debug kernel for Lucid/Maverick/Mainline?

On Thu, Jun 3, 2010 at 6:01 PM, <manoj.iyer@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_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

I feel also worthwhile:

CONFIG_DEBUG_LOCK_ALLOC
CONFIG_PROVE_LOCKING
CONFIG_X86_CHECK_BIOS_CORRUPTION
CONFIG_X86_RESERVE_LOW_64K

Thanks,
Daniel

> 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
>>
>
> --
> kernel-team mailing list
> kernel-team@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team
>



--
Daniel J Blueman

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team
 

Thread Tools




All times are GMT. The time now is 10:44 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org