[poky] [PATCH 0/3] n450: add 2.6.37 kernel recipe and SMP support

Bruce Ashfield bruce.ashfield at gmail.com
Wed Apr 27 17:18:12 PDT 2011


On Wed, Apr 27, 2011 at 6:19 PM, Darren Hart <dvhart at linux.intel.com> wrote:
>
>
> On 04/27/2011 12:59 PM, Bruce Ashfield wrote:
>> On 11-04-27 03:51 PM, Darren Hart wrote:
>>> The atom-pc BSP which the n450 is based on was originally intended for single
>>> CPU. The n450 is a single-core hyperthreaded CPU, so CONFIG_SMP and
>>> CONFIG_SCHED_SMT are required to access the second hardware thread. These
>>> patches add the newly created cfg/smp.scc config fragment to the recipe.
>>>
>>> The current n450 BSP uses linux-yocto-stable (2.6.34), which was an oversight.
>>> These patches add support for the linux-yocto (2.6.37) recipe and separately
>>> enable that as the default. I have tested the linux-yocto kernel and confirmed
>>> it boots, has functional networking, and can suspend and resume.
>>>
>>> After some discussion with Tom, it seems that there is adequate testing planned
>>> for the point release to allow for moving to the linux-yocto recipe. Note that
>>> fixing bug 1010 makes significant changes to whichever kernel we choose
>>
>> Was this supposed to read "does not make significant changes" ? Looks
>> pretty minor to me (outside of jumping kernels :).
>
> Actually no. There was some concern about jumping kernels and I just
> want to point out that enabling SMP changes the way a number of things
> work within the kernel, so some retesting might be necessary anyway. If
> so, then the jump to 2.6.37 isn't as big of a deal.

Aha. Understood, I was thinking in terms of patches/config, or some
other pending changes. But yes, switching to SMP is a under the
covers big change .. but nothing I wouldn't lump into the 'tested by
other BSPs' category I mentioned before.

Cheers,

Bruce

>
>>
>>> to use. Before I commit to meta-intel however, I would like the input of the QA
>>> team.
>>>
>>> How much testing was planned for the n450 originally? How much additional
>>> testing would be required if we make the new kernel the default?
>>
>> For what its worth our other x86 testing should have largely covered
>> this. If we can't count on the transitive value of our testing using
>> the common fragments/drivers/arch, then we don't have much to count on.
>>
>> I see little risk in this myself, and would support the default changing
>> to linux-yocto in 1.0.1.
>
> Excellent point Bruce!
>
>>
>> Acked-by: Bruce Ashfield <bruce.ashfield at windriver.com>
>>
>>>
>>> Thanks,
>>>
>>> Darren Hart
>>>
>>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> _______________________________________________
> poky mailing list
> poky at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"



More information about the poky mailing list