[PATCH 0/2] kernel: consolidated pull request

[PATCH 0/2] kernel: consolidated pull request

[Bruce Ashfield]

Richard/Saul,

Consolidated is a bit of a strong word here, since there are
only two patches .. but I'd rather send them as a series of
my pending changes versus two separate pulls.

Once is an update of the 3.10 tree to include the 3.10 LTSI
content, this gets us new BSP support and a few features. The
merge was smooth, but I did build and boot all qemu boards to
be sure.

The second change is a tweak I made to speed up the kernel
installation phase. It's a simple change that saves nearly a 
minute on my local tests. As the patch states, I kept things
simple instead of getting really arcane with find and mixing
multiple options (it is already getting unreadible, and I
didn't want to make it worse).

From the patch:

    Time for install before this change:

     real    2m48.563s
     user    0m35.220s
     sys     0m33.036s

    Time for install after this change:

     real    1m21.301s
     user    0m33.160s
     sys     0m28.388s

I've been running with the install change for quite some time
now, and haven't seen any breakage.

Bruce

The following changes since commit 82f9c2bcff3e977beefde6048d2ba32d17acbbd0:

  wic: Hook up --debug option (2014-02-04 12:57:36 +0000)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (2):
  kernel: stop using -exec rm for deleting files
  linux-yocto/3.10: integrate LTSI

 meta/classes/kernel.bbclass                        | 18 +++++++++++++++---
 meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb   |  4 ++--
 meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb |  2 +-
 meta/recipes-kernel/linux/linux-yocto_3.10.bb      | 14 +++++++-------
 4 files changed, 25 insertions(+), 13 deletions(-)

-- 
1.8.1.2

[PATCH 1/2] kernel: stop using -exec rm for deleting files

[Bruce Ashfield]

Removing files from the source tree via find, exec and rm is not the
most efficient operation, due to (among other things) the many forked
processes.

If we use -delete, it saves a significant amount of time. But -delete
does not work with -prune (since it forces -depth). To maintain the
lib, tools and scripts source files, we can hide them temporarily,
skip their hidden directories and then finally restore them.

Time for install before this change:

 real    2m48.563s
 user    0m35.220s
 sys     0m33.036s

Time for install after this change:

 real    1m21.301s
 user    0m33.160s
 sys     0m28.388s

We could further speed this up by using inline perl to delete the files,
but that complexity is avoided for now.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/classes/kernel.bbclass | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 51626b03f824..b76a65699755 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -260,9 +260,21 @@ kernel_do_install() {
 	# we clean the scripts dir while leaving the generated config
 	# and include files.
 	#
-	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
-	make -C $kerneldir _mrproper_scripts
-	find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
+	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean _mrproper_scripts 
+
+	# hide directories that shouldn't have their .c, s and S files deleted
+	for d in tools scripts lib; do
+		mv $kerneldir/$d $kerneldir/.$d
+	done
+
+	# delete .c, .s and .S files, unless we hid a directory as .<dir>. This technique is 
+	# much faster than find -prune and -exec
+	find . -not -path '*/\.*' -type f -name "*.[csS]" -delete
+
+	# put the hidden dirs back
+	for d in tools scripts lib; do
+		mv $kerneldir/.$d $kerneldir/$d
+	done
 
 	# As of Linux kernel version 3.0.1, the clean target removes
 	# arch/powerpc/lib/crtsavres.o which is present in
-- 
1.8.1.2

Re: [PATCH 1/2] kernel: stop using -exec rm for deleting files

[Richard Purdie]

On Tue, 2014-02-04 at 12:34 -0500, Bruce Ashfield wrote:
> Removing files from the source tree via find, exec and rm is not the
> most efficient operation, due to (among other things) the many forked
> processes.
> 
> If we use -delete, it saves a significant amount of time. But -delete
> does not work with -prune (since it forces -depth). To maintain the
> lib, tools and scripts source files, we can hide them temporarily,
> skip their hidden directories and then finally restore them.
> 
> Time for install before this change:
> 
>  real    2m48.563s
>  user    0m35.220s
>  sys     0m33.036s
> 
> Time for install after this change:
> 
>  real    1m21.301s
>  user    0m33.160s
>  sys     0m28.388s
> 
> We could further speed this up by using inline perl to delete the files,
> but that complexity is avoided for now.
> 
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  meta/classes/kernel.bbclass | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 51626b03f824..b76a65699755 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -260,9 +260,21 @@ kernel_do_install() {
>  	# we clean the scripts dir while leaving the generated config
>  	# and include files.
>  	#
> -	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
> -	make -C $kerneldir _mrproper_scripts
> -	find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;

If we wanted to keep the single expression like this, we could do
something like:

find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -print0 | xargs -0 rm -f

?

I don't have strong feelings about it, I'm just curious if you tried it
really. The xargs should batch things up enough that the fork overhead
is much less.

Cheers,

Richard


> +	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean _mrproper_scripts 
> +
> +	# hide directories that shouldn't have their .c, s and S files deleted
> +	for d in tools scripts lib; do
> +		mv $kerneldir/$d $kerneldir/.$d
> +	done
> +
> +	# delete .c, .s and .S files, unless we hid a directory as .<dir>. This technique is 
> +	# much faster than find -prune and -exec
> +	find . -not -path '*/\.*' -type f -name "*.[csS]" -delete
> +
> +	# put the hidden dirs back
> +	for d in tools scripts lib; do
> +		mv $kerneldir/.$d $kerneldir/$d
> +	done
>  
>  	# As of Linux kernel version 3.0.1, the clean target removes
>  	# arch/powerpc/lib/crtsavres.o which is present in

Re: [PATCH 1/2] kernel: stop using -exec rm for deleting files

[Bruce Ashfield]

On Tue, Feb 4, 2014 at 6:26 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2014-02-04 at 12:34 -0500, Bruce Ashfield wrote:
>> Removing files from the source tree via find, exec and rm is not the
>> most efficient operation, due to (among other things) the many forked
>> processes.
>>
>> If we use -delete, it saves a significant amount of time. But -delete
>> does not work with -prune (since it forces -depth). To maintain the
>> lib, tools and scripts source files, we can hide them temporarily,
>> skip their hidden directories and then finally restore them.
>>
>> Time for install before this change:
>>
>>  real    2m48.563s
>>  user    0m35.220s
>>  sys     0m33.036s
>>
>> Time for install after this change:
>>
>>  real    1m21.301s
>>  user    0m33.160s
>>  sys     0m28.388s
>>
>> We could further speed this up by using inline perl to delete the files,
>> but that complexity is avoided for now.
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>>  meta/classes/kernel.bbclass | 18 +++++++++++++++---
>>  1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index 51626b03f824..b76a65699755 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -260,9 +260,21 @@ kernel_do_install() {
>>       # we clean the scripts dir while leaving the generated config
>>       # and include files.
>>       #
>> -     oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
>> -     make -C $kerneldir _mrproper_scripts
>> -     find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
>
> If we wanted to keep the single expression like this, we could do
> something like:
>
> find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -print0 | xargs -0 rm -f
>
> ?
>
> I don't have strong feelings about it, I'm just curious if you tried it
> really. The xargs should batch things up enough that the fork overhead
> is much less.

I did try xargs, and a few other things in between. I had a 7 hour plane flight
to look into this (and packaging overhead .. that's next) and I tried
a few other
techniques. As I hinted in my commit message, the fastest is to actually
locate the files with perl and calling unlink() directly .. but that's
even more of
a departure from what we had before :)

find, prune and friends get so unreadable, that when I found the faster way, I
tossed them in the bin and didn't look back!

Cheers,

Bruce

>
> Cheers,
>
> Richard
>
>
>> +     oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean _mrproper_scripts
>> +
>> +     # hide directories that shouldn't have their .c, s and S files deleted
>> +     for d in tools scripts lib; do
>> +             mv $kerneldir/$d $kerneldir/.$d
>> +     done
>> +
>> +     # delete .c, .s and .S files, unless we hid a directory as .<dir>. This technique is
>> +     # much faster than find -prune and -exec
>> +     find . -not -path '*/\.*' -type f -name "*.[csS]" -delete
>> +
>> +     # put the hidden dirs back
>> +     for d in tools scripts lib; do
>> +             mv $kerneldir/.$d $kerneldir/$d
>> +     done
>>
>>       # As of Linux kernel version 3.0.1, the clean target removes
>>       # arch/powerpc/lib/crtsavres.o which is present in
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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

Re: [PATCH 1/2] kernel: stop using -exec rm for deleting files

[Paul Barker]

On 5 February 2014 00:35, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
> On Tue, Feb 4, 2014 at 6:26 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Tue, 2014-02-04 at 12:34 -0500, Bruce Ashfield wrote:
>>> Removing files from the source tree via find, exec and rm is not the
>>> most efficient operation, due to (among other things) the many forked
>>> processes.
>>>
>>> If we use -delete, it saves a significant amount of time. But -delete
>>> does not work with -prune (since it forces -depth). To maintain the
>>> lib, tools and scripts source files, we can hide them temporarily,
>>> skip their hidden directories and then finally restore them.
>>>
>>> Time for install before this change:
>>>
>>>  real    2m48.563s
>>>  user    0m35.220s
>>>  sys     0m33.036s
>>>
>>> Time for install after this change:
>>>
>>>  real    1m21.301s
>>>  user    0m33.160s
>>>  sys     0m28.388s
>>>
>>> We could further speed this up by using inline perl to delete the files,
>>> but that complexity is avoided for now.
>>>
>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>>> ---
>>>  meta/classes/kernel.bbclass | 18 +++++++++++++++---
>>>  1 file changed, 15 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>>> index 51626b03f824..b76a65699755 100644
>>> --- a/meta/classes/kernel.bbclass
>>> +++ b/meta/classes/kernel.bbclass
>>> @@ -260,9 +260,21 @@ kernel_do_install() {
>>>       # we clean the scripts dir while leaving the generated config
>>>       # and include files.
>>>       #
>>> -     oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
>>> -     make -C $kerneldir _mrproper_scripts
>>> -     find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
>>
>> If we wanted to keep the single expression like this, we could do
>> something like:
>>
>> find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -print0 | xargs -0 rm -f
>>
>> ?
>>
>> I don't have strong feelings about it, I'm just curious if you tried it
>> really. The xargs should batch things up enough that the fork overhead
>> is much less.
>
> I did try xargs, and a few other things in between. I had a 7 hour plane flight
> to look into this (and packaging overhead .. that's next) and I tried
> a few other
> techniques. As I hinted in my commit message, the fastest is to actually
> locate the files with perl and calling unlink() directly .. but that's
> even more of
> a departure from what we had before :)
>
> find, prune and friends get so unreadable, that when I found the faster way, I
> tossed them in the bin and didn't look back!
>

How does """find $kerneldir -not -regex
$kerneldir'/\(lib\|tools\|scripts)/.*' -type f -name "*.[csS]"
-delete""" stack up?

-- 
Paul Barker

Email: paul@paulbarker.me.uk
http://www.paulbarker.me.uk

Re: [PATCH 1/2] kernel: stop using -exec rm for deleting files

[Bruce Ashfield]

On Tue, Feb 4, 2014 at 8:36 PM, Paul Barker <paul@paulbarker.me.uk> wrote:
> On 5 February 2014 00:35, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>> On Tue, Feb 4, 2014 at 6:26 PM, Richard Purdie
>> <richard.purdie@linuxfoundation.org> wrote:
>>> On Tue, 2014-02-04 at 12:34 -0500, Bruce Ashfield wrote:
>>>> Removing files from the source tree via find, exec and rm is not the
>>>> most efficient operation, due to (among other things) the many forked
>>>> processes.
>>>>
>>>> If we use -delete, it saves a significant amount of time. But -delete
>>>> does not work with -prune (since it forces -depth). To maintain the
>>>> lib, tools and scripts source files, we can hide them temporarily,
>>>> skip their hidden directories and then finally restore them.
>>>>
>>>> Time for install before this change:
>>>>
>>>>  real    2m48.563s
>>>>  user    0m35.220s
>>>>  sys     0m33.036s
>>>>
>>>> Time for install after this change:
>>>>
>>>>  real    1m21.301s
>>>>  user    0m33.160s
>>>>  sys     0m28.388s
>>>>
>>>> We could further speed this up by using inline perl to delete the files,
>>>> but that complexity is avoided for now.
>>>>
>>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>>>> ---
>>>>  meta/classes/kernel.bbclass | 18 +++++++++++++++---
>>>>  1 file changed, 15 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>>>> index 51626b03f824..b76a65699755 100644
>>>> --- a/meta/classes/kernel.bbclass
>>>> +++ b/meta/classes/kernel.bbclass
>>>> @@ -260,9 +260,21 @@ kernel_do_install() {
>>>>       # we clean the scripts dir while leaving the generated config
>>>>       # and include files.
>>>>       #
>>>> -     oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
>>>> -     make -C $kerneldir _mrproper_scripts
>>>> -     find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
>>>
>>> If we wanted to keep the single expression like this, we could do
>>> something like:
>>>
>>> find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -print0 | xargs -0 rm -f
>>>
>>> ?
>>>
>>> I don't have strong feelings about it, I'm just curious if you tried it
>>> really. The xargs should batch things up enough that the fork overhead
>>> is much less.
>>
>> I did try xargs, and a few other things in between. I had a 7 hour plane flight
>> to look into this (and packaging overhead .. that's next) and I tried
>> a few other
>> techniques. As I hinted in my commit message, the fastest is to actually
>> locate the files with perl and calling unlink() directly .. but that's
>> even more of
>> a departure from what we had before :)
>>
>> find, prune and friends get so unreadable, that when I found the faster way, I
>> tossed them in the bin and didn't look back!
>>
>
> How does """find $kerneldir -not -regex
> $kerneldir'/\(lib\|tools\|scripts)/.*' -type f -name "*.[csS]"
> -delete""" stack up?

timewise it is similar, but I could have cooked that up myself .. I just don't
like incantations of find and its arcane options.

Bruce

>
> --
> Paul Barker
>
> Email: paul@paulbarker.me.uk
> http://www.paulbarker.me.uk



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

Re: [PATCH 1/2] kernel: stop using -exec rm for deleting files

[Richard Purdie]

On Tue, 2014-02-04 at 12:34 -0500, Bruce Ashfield wrote:
> Removing files from the source tree via find, exec and rm is not the
> most efficient operation, due to (among other things) the many forked
> processes.
> 
> If we use -delete, it saves a significant amount of time. But -delete
> does not work with -prune (since it forces -depth). To maintain the
> lib, tools and scripts source files, we can hide them temporarily,
> skip their hidden directories and then finally restore them.
> 
> Time for install before this change:
> 
>  real    2m48.563s
>  user    0m35.220s
>  sys     0m33.036s
> 
> Time for install after this change:
> 
>  real    1m21.301s
>  user    0m33.160s
>  sys     0m28.388s
> 
> We could further speed this up by using inline perl to delete the files,
> but that complexity is avoided for now.
> 
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  meta/classes/kernel.bbclass | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 51626b03f824..b76a65699755 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -260,9 +260,21 @@ kernel_do_install() {
>  	# we clean the scripts dir while leaving the generated config
>  	# and include files.
>  	#
> -	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
> -	make -C $kerneldir _mrproper_scripts
> -	find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
> +	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean _mrproper_scripts 
> +
> +	# hide directories that shouldn't have their .c, s and S files deleted
> +	for d in tools scripts lib; do
> +		mv $kerneldir/$d $kerneldir/.$d
> +	done
> +
> +	# delete .c, .s and .S files, unless we hid a directory as .<dir>. This technique is 
> +	# much faster than find -prune and -exec
> +	find . -not -path '*/\.*' -type f -name "*.[csS]" -delete
> +
> +	# put the hidden dirs back
> +	for d in tools scripts lib; do
> +		mv $kerneldir/.$d $kerneldir/$d
> +	done
>  
>  	# As of Linux kernel version 3.0.1, the clean target removes
>  	# arch/powerpc/lib/crtsavres.o which is present in


I think this patch is resulting in:

http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc-lsb/builds/22/steps/BuildImages/logs/stdio

Cheers,

Richard

Re: [PATCH 1/2] kernel: stop using -exec rm for deleting files

[Bruce Ashfield]

On Sun, Feb 9, 2014 at 7:06 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2014-02-04 at 12:34 -0500, Bruce Ashfield wrote:
>> Removing files from the source tree via find, exec and rm is not the
>> most efficient operation, due to (among other things) the many forked
>> processes.
>>
>> If we use -delete, it saves a significant amount of time. But -delete
>> does not work with -prune (since it forces -depth). To maintain the
>> lib, tools and scripts source files, we can hide them temporarily,
>> skip their hidden directories and then finally restore them.
>>
>> Time for install before this change:
>>
>>  real    2m48.563s
>>  user    0m35.220s
>>  sys     0m33.036s
>>
>> Time for install after this change:
>>
>>  real    1m21.301s
>>  user    0m33.160s
>>  sys     0m28.388s
>>
>> We could further speed this up by using inline perl to delete the files,
>> but that complexity is avoided for now.
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>>  meta/classes/kernel.bbclass | 18 +++++++++++++++---
>>  1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index 51626b03f824..b76a65699755 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -260,9 +260,21 @@ kernel_do_install() {
>>       # we clean the scripts dir while leaving the generated config
>>       # and include files.
>>       #
>> -     oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
>> -     make -C $kerneldir _mrproper_scripts
>> -     find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
>> +     oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean _mrproper_scripts
>> +
>> +     # hide directories that shouldn't have their .c, s and S files deleted
>> +     for d in tools scripts lib; do
>> +             mv $kerneldir/$d $kerneldir/.$d
>> +     done
>> +
>> +     # delete .c, .s and .S files, unless we hid a directory as .<dir>. This technique is
>> +     # much faster than find -prune and -exec
>> +     find . -not -path '*/\.*' -type f -name "*.[csS]" -delete
>> +
>> +     # put the hidden dirs back
>> +     for d in tools scripts lib; do
>> +             mv $kerneldir/.$d $kerneldir/$d
>> +     done
>>
>>       # As of Linux kernel version 3.0.1, the clean target removes
>>       # arch/powerpc/lib/crtsavres.o which is present in
>
>
> I think this patch is resulting in:
>
> http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc-lsb/builds/22/steps/BuildImages/logs/stdio
>

Could be. I'll launch a build and see if it happens here as well.

Bruce

> Cheers,
>
> Richard
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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

Re: [PATCH 1/2] kernel: stop using -exec rm for deleting files

[Bruce Ashfield]

On 14-02-09 07:06 AM, Richard Purdie wrote:
> On Tue, 2014-02-04 at 12:34 -0500, Bruce Ashfield wrote:
>> Removing files from the source tree via find, exec and rm is not the
>> most efficient operation, due to (among other things) the many forked
>> processes.
>>
>> If we use -delete, it saves a significant amount of time. But -delete
>> does not work with -prune (since it forces -depth). To maintain the
>> lib, tools and scripts source files, we can hide them temporarily,
>> skip their hidden directories and then finally restore them.
>>
>> Time for install before this change:
>>
>>   real    2m48.563s
>>   user    0m35.220s
>>   sys     0m33.036s
>>
>> Time for install after this change:
>>
>>   real    1m21.301s
>>   user    0m33.160s
>>   sys     0m28.388s
>>
>> We could further speed this up by using inline perl to delete the files,
>> but that complexity is avoided for now.
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>>   meta/classes/kernel.bbclass | 18 +++++++++++++++---
>>   1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index 51626b03f824..b76a65699755 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -260,9 +260,21 @@ kernel_do_install() {
>>   	# we clean the scripts dir while leaving the generated config
>>   	# and include files.
>>   	#
>> -	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
>> -	make -C $kerneldir _mrproper_scripts
>> -	find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
>> +	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean _mrproper_scripts
>> +
>> +	# hide directories that shouldn't have their .c, s and S files deleted
>> +	for d in tools scripts lib; do
>> +		mv $kerneldir/$d $kerneldir/.$d
>> +	done
>> +
>> +	# delete .c, .s and .S files, unless we hid a directory as .<dir>. This technique is
>> +	# much faster than find -prune and -exec
>> +	find . -not -path '*/\.*' -type f -name "*.[csS]" -delete
>> +
>> +	# put the hidden dirs back
>> +	for d in tools scripts lib; do
>> +		mv $kerneldir/.$d $kerneldir/$d
>> +	done
>>
>>   	# As of Linux kernel version 3.0.1, the clean target removes
>>   	# arch/powerpc/lib/crtsavres.o which is present in
>
>
> I think this patch is resulting in:
>
> http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc-lsb/builds/22/steps/BuildImages/logs/stdio

I've reproduced the issue locally, patch should be incoming shortly.

Bruce

>
> Cheers,
>
> Richard
>
>
>

Re: [PATCH 1/2] kernel: stop using -exec rm for deleting files

[Bruce Ashfield]

On 14-02-09 07:06 AM, Richard Purdie wrote:
> On Tue, 2014-02-04 at 12:34 -0500, Bruce Ashfield wrote:
>> Removing files from the source tree via find, exec and rm is not the
>> most efficient operation, due to (among other things) the many forked
>> processes.
>>
>> If we use -delete, it saves a significant amount of time. But -delete
>> does not work with -prune (since it forces -depth). To maintain the
>> lib, tools and scripts source files, we can hide them temporarily,
>> skip their hidden directories and then finally restore them.
>>
>> Time for install before this change:
>>
>>   real    2m48.563s
>>   user    0m35.220s
>>   sys     0m33.036s
>>
>> Time for install after this change:
>>
>>   real    1m21.301s
>>   user    0m33.160s
>>   sys     0m28.388s
>>
>> We could further speed this up by using inline perl to delete the files,
>> but that complexity is avoided for now.
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>>   meta/classes/kernel.bbclass | 18 +++++++++++++++---
>>   1 file changed, 15 insertions(+), 3 deletions(-)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index 51626b03f824..b76a65699755 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -260,9 +260,21 @@ kernel_do_install() {
>>   	# we clean the scripts dir while leaving the generated config
>>   	# and include files.
>>   	#
>> -	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
>> -	make -C $kerneldir _mrproper_scripts
>> -	find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
>> +	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean _mrproper_scripts
>> +
>> +	# hide directories that shouldn't have their .c, s and S files deleted
>> +	for d in tools scripts lib; do
>> +		mv $kerneldir/$d $kerneldir/.$d
>> +	done
>> +
>> +	# delete .c, .s and .S files, unless we hid a directory as .<dir>. This technique is
>> +	# much faster than find -prune and -exec
>> +	find . -not -path '*/\.*' -type f -name "*.[csS]" -delete
>> +
>> +	# put the hidden dirs back
>> +	for d in tools scripts lib; do
>> +		mv $kerneldir/.$d $kerneldir/$d
>> +	done
>>
>>   	# As of Linux kernel version 3.0.1, the clean target removes
>>   	# arch/powerpc/lib/crtsavres.o which is present in
>
>
> I think this patch is resulting in:
>
> http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc-lsb/builds/22/steps/BuildImages/logs/stdio

I've fixed this now.

For staged patches, do you prefer a resend or an incremental update patch ?

Bruce

>
> Cheers,
>
> Richard
>
>
>

Re: [PATCH 1/2] kernel: stop using -exec rm for deleting files

[Richard Purdie]

On Mon, 2014-02-10 at 12:17 -0500, Bruce Ashfield wrote:
> On 14-02-09 07:06 AM, Richard Purdie wrote:
> > On Tue, 2014-02-04 at 12:34 -0500, Bruce Ashfield wrote:
> >> Removing files from the source tree via find, exec and rm is not the
> >> most efficient operation, due to (among other things) the many forked
> >> processes.
> >>
> >> If we use -delete, it saves a significant amount of time. But -delete
> >> does not work with -prune (since it forces -depth). To maintain the
> >> lib, tools and scripts source files, we can hide them temporarily,
> >> skip their hidden directories and then finally restore them.
> >>
> >> Time for install before this change:
> >>
> >>   real    2m48.563s
> >>   user    0m35.220s
> >>   sys     0m33.036s
> >>
> >> Time for install after this change:
> >>
> >>   real    1m21.301s
> >>   user    0m33.160s
> >>   sys     0m28.388s
> >>
> >> We could further speed this up by using inline perl to delete the files,
> >> but that complexity is avoided for now.
> >>
> >> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> >> ---
> >>   meta/classes/kernel.bbclass | 18 +++++++++++++++---
> >>   1 file changed, 15 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> >> index 51626b03f824..b76a65699755 100644
> >> --- a/meta/classes/kernel.bbclass
> >> +++ b/meta/classes/kernel.bbclass
> >> @@ -260,9 +260,21 @@ kernel_do_install() {
> >>   	# we clean the scripts dir while leaving the generated config
> >>   	# and include files.
> >>   	#
> >> -	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean
> >> -	make -C $kerneldir _mrproper_scripts
> >> -	find $kerneldir -path $kerneldir/lib -prune -o -path $kerneldir/tools -prune -o -path $kerneldir/scripts -prune -o -name "*.[csS]" -exec rm '{}' \;
> >> +	oe_runmake -C $kerneldir CC="${KERNEL_CC}" LD="${KERNEL_LD}" clean _mrproper_scripts
> >> +
> >> +	# hide directories that shouldn't have their .c, s and S files deleted
> >> +	for d in tools scripts lib; do
> >> +		mv $kerneldir/$d $kerneldir/.$d
> >> +	done
> >> +
> >> +	# delete .c, .s and .S files, unless we hid a directory as .<dir>. This technique is
> >> +	# much faster than find -prune and -exec
> >> +	find . -not -path '*/\.*' -type f -name "*.[csS]" -delete
> >> +
> >> +	# put the hidden dirs back
> >> +	for d in tools scripts lib; do
> >> +		mv $kerneldir/.$d $kerneldir/$d
> >> +	done
> >>
> >>   	# As of Linux kernel version 3.0.1, the clean target removes
> >>   	# arch/powerpc/lib/crtsavres.o which is present in
> >
> >
> > I think this patch is resulting in:
> >
> > http://autobuilder.yoctoproject.org/main/builders/nightly-fsl-ppc-lsb/builds/22/steps/BuildImages/logs/stdio
> 
> I've fixed this now.
> 
> For staged patches, do you prefer a resend or an incremental update patch ?

A resend is fine thanks.

Cheers,

Richard

[PATCH 2/2] linux-yocto/3.10: integrate LTSI

[Bruce Ashfield]

Updating the SRCREVs of the 3.10 tree to reflect the integration of
of commit 68054859 from:

    git://git.linuxfoundation.org/ltsi-kernegit://git.linuxfoundation.org/ltsi-kernel.git

Build and boot tested on all qemu architectures.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb   |  4 ++--
 meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb |  2 +-
 meta/recipes-kernel/linux/linux-yocto_3.10.bb      | 14 +++++++-------
 3 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
index 9bdd47ecbf65..dd1ec52626d1 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
@@ -3,8 +3,8 @@ require recipes-kernel/linux/linux-yocto.inc
 KBRANCH = "standard/preempt-rt/base"
 KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
 
-SRCREV_machine ?= "957ba6ae6c1d81b57da6a36b93f1b2a0ced2f45d"
-SRCREV_machine_qemuppc ?= "37e40b7017a9c78d676b19716011494dc7cb6369"
+SRCREV_machine ?= "14651317755a87f03f8399299f2eb0b4042a2d0c"
+SRCREV_machine_qemuppc ?= "2918b5d9ee82304d67aae61a427fcb02d3edee8f"
 SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
index 6defed1c9464..a852f75ff443 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
@@ -9,7 +9,7 @@ LINUX_VERSION ?= "3.10.25"
 
 KMETA = "meta"
 
-SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
+SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
 SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.10.bb b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
index d0772fddc5f1..f7f4dabea8d5 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
@@ -11,13 +11,13 @@ KBRANCH_qemux86  = "standard/common-pc/base"
 KBRANCH_qemux86-64  = "standard/common-pc-64/base"
 KBRANCH_qemumips64 = "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "e3163012f3e09fe48374ef22bc676f8b19aeec1a"
-SRCREV_machine_qemumips ?= "01a71aaf8e545c3ef88da1fe02f53d1b96a2640e"
-SRCREV_machine_qemuppc ?= "ae1b9115975ff235038d5da22b4cc984b4d76aae"
-SRCREV_machine_qemux86 ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
-SRCREV_machine_qemux86-64 ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
-SRCREV_machine_qemumips64 ?= "67efb2993ec7726df5567e2572fd64e34e29b46d"
-SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
+SRCREV_machine_qemuarm ?= "2a4d8c0884c8d08896c052a6e42c51e861cf48b5"
+SRCREV_machine_qemumips ?= "08872a160571b9bf45b6cd262b977063f12aca46"
+SRCREV_machine_qemuppc ?= "eba0c4fcc962ffddd384251b5b6ee0c61bd5ea4d"
+SRCREV_machine_qemux86 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
+SRCREV_machine_qemux86-64 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
+SRCREV_machine_qemumips64 ?= "de555074575d2997a8cd7a4b2d6dbf22e7ddfc9b"
+SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
 SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
-- 
1.8.1.2

Re: [PATCH 2/2] linux-yocto/3.10: integrate LTSI

[Saul Wold]

On 02/04/2014 09:34 AM, Bruce Ashfield wrote:
> Updating the SRCREVs of the 3.10 tree to reflect the integration of
> of commit 68054859 from:
>
>      git://git.linuxfoundation.org/ltsi-kernegit://git.linuxfoundation.org/ltsi-kernel.git
>
> Build and boot tested on all qemu architectures.
>
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>   meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb   |  4 ++--
>   meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb |  2 +-
>   meta/recipes-kernel/linux/linux-yocto_3.10.bb      | 14 +++++++-------
>   3 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
> index 9bdd47ecbf65..dd1ec52626d1 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
> @@ -3,8 +3,8 @@ require recipes-kernel/linux/linux-yocto.inc
>   KBRANCH = "standard/preempt-rt/base"
>   KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
>
> -SRCREV_machine ?= "957ba6ae6c1d81b57da6a36b93f1b2a0ced2f45d"
> -SRCREV_machine_qemuppc ?= "37e40b7017a9c78d676b19716011494dc7cb6369"
> +SRCREV_machine ?= "14651317755a87f03f8399299f2eb0b4042a2d0c"
> +SRCREV_machine_qemuppc ?= "2918b5d9ee82304d67aae61a427fcb02d3edee8f"
>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>
>   SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
> index 6defed1c9464..a852f75ff443 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
> @@ -9,7 +9,7 @@ LINUX_VERSION ?= "3.10.25"
>
>   KMETA = "meta"
>
> -SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
> +SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>
>   PV = "${LINUX_VERSION}+git${SRCPV}"
> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.10.bb b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
> index d0772fddc5f1..f7f4dabea8d5 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
> @@ -11,13 +11,13 @@ KBRANCH_qemux86  = "standard/common-pc/base"
>   KBRANCH_qemux86-64  = "standard/common-pc-64/base"
>   KBRANCH_qemumips64 = "standard/mti-malta64"
>
> -SRCREV_machine_qemuarm ?= "e3163012f3e09fe48374ef22bc676f8b19aeec1a"
> -SRCREV_machine_qemumips ?= "01a71aaf8e545c3ef88da1fe02f53d1b96a2640e"
> -SRCREV_machine_qemuppc ?= "ae1b9115975ff235038d5da22b4cc984b4d76aae"
> -SRCREV_machine_qemux86 ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
> -SRCREV_machine_qemux86-64 ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
> -SRCREV_machine_qemumips64 ?= "67efb2993ec7726df5567e2572fd64e34e29b46d"
> -SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
> +SRCREV_machine_qemuarm ?= "2a4d8c0884c8d08896c052a6e42c51e861cf48b5"
> +SRCREV_machine_qemumips ?= "08872a160571b9bf45b6cd262b977063f12aca46"
> +SRCREV_machine_qemuppc ?= "eba0c4fcc962ffddd384251b5b6ee0c61bd5ea4d"
> +SRCREV_machine_qemux86 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
> +SRCREV_machine_qemux86-64 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
> +SRCREV_machine_qemumips64 ?= "de555074575d2997a8cd7a4b2d6dbf22e7ddfc9b"
> +SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>
>   SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
>

This change seems to have introduced an issue with the x86* builds as 
follows:
> | drivers/built-in.o: In function `gen6_update_ring_freq':
> | /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/build/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/linux/drivers/gpu/drm/i915/intel_pm.c:3876: undefined reference to `cpufreq_cpu_get'
> | /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/build/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/linux/drivers/gpu/drm/i915/intel_pm.c:3879: undefined reference to `cpufreq_cpu_put'
> | make[2]: *** [vmlinux] Error 1
> | make[1]: *** [sub-make] Error 2
> | make: *** [all] Error 2
> | ERROR: oe_runmake failed
> | WARNING: /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/build/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/temp/run.do_compile.1426:1 exit 1 from
> |   exit 1
> | ERROR: Function failed: do_compile (log file is located at /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/build/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/temp/log.do_compile.1426)
> NOTE: recipe linux-yocto-3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0: task do_compile: Failed
> ERROR: Task 149 (/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/meta/recipes-kernel/linux/linux-yocto_3.10.bb, do_compile) failed with exit code '1'
> NOTE: recipe gcc-runtime-4.8.2-r0: task do_compile: Succeeded

This can be seen on the AB 
http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/20/steps/BuildImages/logs/stdio

This is one example.

Thanks
	Sau!

Re: [PATCH 2/2] linux-yocto/3.10: integrate LTSI

[Bruce Ashfield]

On 14-02-07 11:42 AM, Saul Wold wrote:
> On 02/04/2014 09:34 AM, Bruce Ashfield wrote:
>> Updating the SRCREVs of the 3.10 tree to reflect the integration of
>> of commit 68054859 from:
>>
>>
>> git://git.linuxfoundation.org/ltsi-kernegit://git.linuxfoundation.org/ltsi-kernel.git
>>
>>
>> Build and boot tested on all qemu architectures.
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>>   meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb   |  4 ++--
>>   meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb |  2 +-
>>   meta/recipes-kernel/linux/linux-yocto_3.10.bb      | 14 +++++++-------
>>   3 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>> b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>> index 9bdd47ecbf65..dd1ec52626d1 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>> @@ -3,8 +3,8 @@ require recipes-kernel/linux/linux-yocto.inc
>>   KBRANCH = "standard/preempt-rt/base"
>>   KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
>>
>> -SRCREV_machine ?= "957ba6ae6c1d81b57da6a36b93f1b2a0ced2f45d"
>> -SRCREV_machine_qemuppc ?= "37e40b7017a9c78d676b19716011494dc7cb6369"
>> +SRCREV_machine ?= "14651317755a87f03f8399299f2eb0b4042a2d0c"
>> +SRCREV_machine_qemuppc ?= "2918b5d9ee82304d67aae61a427fcb02d3edee8f"
>>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>
>>   SRC_URI =
>> "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
>>
>> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>> b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>> index 6defed1c9464..a852f75ff443 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>> @@ -9,7 +9,7 @@ LINUX_VERSION ?= "3.10.25"
>>
>>   KMETA = "meta"
>>
>> -SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>> +SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>
>>   PV = "${LINUX_VERSION}+git${SRCPV}"
>> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>> b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>> index d0772fddc5f1..f7f4dabea8d5 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>> @@ -11,13 +11,13 @@ KBRANCH_qemux86  = "standard/common-pc/base"
>>   KBRANCH_qemux86-64  = "standard/common-pc-64/base"
>>   KBRANCH_qemumips64 = "standard/mti-malta64"
>>
>> -SRCREV_machine_qemuarm ?= "e3163012f3e09fe48374ef22bc676f8b19aeec1a"
>> -SRCREV_machine_qemumips ?= "01a71aaf8e545c3ef88da1fe02f53d1b96a2640e"
>> -SRCREV_machine_qemuppc ?= "ae1b9115975ff235038d5da22b4cc984b4d76aae"
>> -SRCREV_machine_qemux86 ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>> -SRCREV_machine_qemux86-64 ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>> -SRCREV_machine_qemumips64 ?= "67efb2993ec7726df5567e2572fd64e34e29b46d"
>> -SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>> +SRCREV_machine_qemuarm ?= "2a4d8c0884c8d08896c052a6e42c51e861cf48b5"
>> +SRCREV_machine_qemumips ?= "08872a160571b9bf45b6cd262b977063f12aca46"
>> +SRCREV_machine_qemuppc ?= "eba0c4fcc962ffddd384251b5b6ee0c61bd5ea4d"
>> +SRCREV_machine_qemux86 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>> +SRCREV_machine_qemux86-64 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>> +SRCREV_machine_qemumips64 ?= "de555074575d2997a8cd7a4b2d6dbf22e7ddfc9b"
>> +SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>
>>   SRC_URI =
>> "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
>>
>>
>
> This change seems to have introduced an issue with the x86* builds as

Adding Darren, since qemux86 builds just fine. We'll need his eyes on
the actual failure and fix.

Bruce

> follows:
>> | drivers/built-in.o: In function `gen6_update_ring_freq':
>> |
>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/build/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/linux/drivers/gpu/drm/i915/intel_pm.c:3876:
>> undefined reference to `cpufreq_cpu_get'
>> |
>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/build/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/linux/drivers/gpu/drm/i915/intel_pm.c:3879:
>> undefined reference to `cpufreq_cpu_put'
>> | make[2]: *** [vmlinux] Error 1
>> | make[1]: *** [sub-make] Error 2
>> | make: *** [all] Error 2
>> | ERROR: oe_runmake failed
>> | WARNING:
>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/build/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/temp/run.do_compile.1426:1
>> exit 1 from
>> |   exit 1
>> | ERROR: Function failed: do_compile (log file is located at
>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/build/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/temp/log.do_compile.1426)
>>
>> NOTE: recipe linux-yocto-3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0:
>> task do_compile: Failed
>> ERROR: Task 149
>> (/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/meta/recipes-kernel/linux/linux-yocto_3.10.bb,
>> do_compile) failed with exit code '1'
>> NOTE: recipe gcc-runtime-4.8.2-r0: task do_compile: Succeeded
>
> This can be seen on the AB
> http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/20/steps/BuildImages/logs/stdio
>
>
> This is one example.
>
> Thanks
>      Sau!
>
>

Re: [PATCH 2/2] linux-yocto/3.10: integrate LTSI

[Darren Hart]

Nitin - please join me in looking into what's happening here.

On 2/7/14, 8:44, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:

>On 14-02-07 11:42 AM, Saul Wold wrote:
>> On 02/04/2014 09:34 AM, Bruce Ashfield wrote:
>>> Updating the SRCREVs of the 3.10 tree to reflect the integration of
>>> of commit 68054859 from:
>>>
>>>
>>> 
>>>git://git.linuxfoundation.org/ltsi-kernegit://git.linuxfoundation.org/lt
>>>si-kernel.git
>>>
>>>
>>> Build and boot tested on all qemu architectures.
>>>
>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>>> ---
>>>   meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb   |  4 ++--
>>>   meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb |  2 +-
>>>   meta/recipes-kernel/linux/linux-yocto_3.10.bb      | 14
>>>+++++++-------
>>>   3 files changed, 10 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>>> b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>>> index 9bdd47ecbf65..dd1ec52626d1 100644
>>> --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>>> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>>> @@ -3,8 +3,8 @@ require recipes-kernel/linux/linux-yocto.inc
>>>   KBRANCH = "standard/preempt-rt/base"
>>>   KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
>>>
>>> -SRCREV_machine ?= "957ba6ae6c1d81b57da6a36b93f1b2a0ced2f45d"
>>> -SRCREV_machine_qemuppc ?= "37e40b7017a9c78d676b19716011494dc7cb6369"
>>> +SRCREV_machine ?= "14651317755a87f03f8399299f2eb0b4042a2d0c"
>>> +SRCREV_machine_qemuppc ?= "2918b5d9ee82304d67aae61a427fcb02d3edee8f"
>>>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>>
>>>   SRC_URI =
>>> 
>>>"git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KB
>>>RANCH},meta;name=machine,meta"
>>>
>>> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>>> b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>>> index 6defed1c9464..a852f75ff443 100644
>>> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>>> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>>> @@ -9,7 +9,7 @@ LINUX_VERSION ?= "3.10.25"
>>>
>>>   KMETA = "meta"
>>>
>>> -SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>>> +SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>>
>>>   PV = "${LINUX_VERSION}+git${SRCPV}"
>>> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>>> b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>>> index d0772fddc5f1..f7f4dabea8d5 100644
>>> --- a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>>> +++ b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>>> @@ -11,13 +11,13 @@ KBRANCH_qemux86  = "standard/common-pc/base"
>>>   KBRANCH_qemux86-64  = "standard/common-pc-64/base"
>>>   KBRANCH_qemumips64 = "standard/mti-malta64"
>>>
>>> -SRCREV_machine_qemuarm ?= "e3163012f3e09fe48374ef22bc676f8b19aeec1a"
>>> -SRCREV_machine_qemumips ?= "01a71aaf8e545c3ef88da1fe02f53d1b96a2640e"
>>> -SRCREV_machine_qemuppc ?= "ae1b9115975ff235038d5da22b4cc984b4d76aae"
>>> -SRCREV_machine_qemux86 ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>>> -SRCREV_machine_qemux86-64 ?=
>>>"79af968f2f26378798aec7a6d729ff5a371aae5f"
>>> -SRCREV_machine_qemumips64 ?=
>>>"67efb2993ec7726df5567e2572fd64e34e29b46d"
>>> -SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>>> +SRCREV_machine_qemuarm ?= "2a4d8c0884c8d08896c052a6e42c51e861cf48b5"
>>> +SRCREV_machine_qemumips ?= "08872a160571b9bf45b6cd262b977063f12aca46"
>>> +SRCREV_machine_qemuppc ?= "eba0c4fcc962ffddd384251b5b6ee0c61bd5ea4d"
>>> +SRCREV_machine_qemux86 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>> +SRCREV_machine_qemux86-64 ?=
>>>"78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>> +SRCREV_machine_qemumips64 ?=
>>>"de555074575d2997a8cd7a4b2d6dbf22e7ddfc9b"
>>> +SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>>
>>>   SRC_URI =
>>> 
>>>"git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KB
>>>RANCH},${KMETA};name=machine,meta"
>>>
>>>
>>
>> This change seems to have introduced an issue with the x86* builds as
>
>Adding Darren, since qemux86 builds just fine. We'll need his eyes on
>the actual failure and fix.
>
>Bruce
>
>> follows:
>>> | drivers/built-in.o: In function `gen6_update_ring_freq':
>>> |
>>> 
>>>/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/buil
>>>d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_
>>>78d2a615b1-r0/linux/drivers/gpu/drm/i915/intel_pm.c:3876:
>>> undefined reference to `cpufreq_cpu_get'
>>> |
>>> 
>>>/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/buil
>>>d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_
>>>78d2a615b1-r0/linux/drivers/gpu/drm/i915/intel_pm.c:3879:
>>> undefined reference to `cpufreq_cpu_put'
>>> | make[2]: *** [vmlinux] Error 1
>>> | make[1]: *** [sub-make] Error 2
>>> | make: *** [all] Error 2
>>> | ERROR: oe_runmake failed
>>> | WARNING:
>>> 
>>>/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/buil
>>>d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_
>>>78d2a615b1-r0/temp/run.do_compile.1426:1
>>> exit 1 from
>>> |   exit 1
>>> | ERROR: Function failed: do_compile (log file is located at
>>> 
>>>/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/buil
>>>d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_
>>>78d2a615b1-r0/temp/log.do_compile.1426)
>>>
>>> NOTE: recipe linux-yocto-3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0:
>>> task do_compile: Failed
>>> ERROR: Task 149
>>> 
>>>(/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/met
>>>a/recipes-kernel/linux/linux-yocto_3.10.bb,
>>> do_compile) failed with exit code '1'
>>> NOTE: recipe gcc-runtime-4.8.2-r0: task do_compile: Succeeded
>>
>> This can be seen on the AB
>> 
>>http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/20/s
>>teps/BuildImages/logs/stdio
>>
>>
>> This is one example.
>>
>> Thanks
>>      Sau!
>>
>>
>
>

Re: [PATCH 2/2] linux-yocto/3.10: integrate LTSI

[Darren Hart]

Erm, and Nitin Cc'd this time. Sigh. Always a hoot.

On 2/7/14, 8:46, "Darren Hart" <dvhart@linux.intel.com> wrote:

>Nitin - please join me in looking into what's happening here.
>
>On 2/7/14, 8:44, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
>
>>On 14-02-07 11:42 AM, Saul Wold wrote:
>>> On 02/04/2014 09:34 AM, Bruce Ashfield wrote:
>>>> Updating the SRCREVs of the 3.10 tree to reflect the integration of
>>>> of commit 68054859 from:
>>>>
>>>>
>>>> 
>>>>git://git.linuxfoundation.org/ltsi-kernegit://git.linuxfoundation.org/l
>>>>t
>>>>si-kernel.git
>>>>
>>>>
>>>> Build and boot tested on all qemu architectures.
>>>>
>>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>>>> ---
>>>>   meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb   |  4 ++--
>>>>   meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb |  2 +-
>>>>   meta/recipes-kernel/linux/linux-yocto_3.10.bb      | 14
>>>>+++++++-------
>>>>   3 files changed, 10 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>>>> b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>>>> index 9bdd47ecbf65..dd1ec52626d1 100644
>>>> --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>>>> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>>>> @@ -3,8 +3,8 @@ require recipes-kernel/linux/linux-yocto.inc
>>>>   KBRANCH = "standard/preempt-rt/base"
>>>>   KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
>>>>
>>>> -SRCREV_machine ?= "957ba6ae6c1d81b57da6a36b93f1b2a0ced2f45d"
>>>> -SRCREV_machine_qemuppc ?= "37e40b7017a9c78d676b19716011494dc7cb6369"
>>>> +SRCREV_machine ?= "14651317755a87f03f8399299f2eb0b4042a2d0c"
>>>> +SRCREV_machine_qemuppc ?= "2918b5d9ee82304d67aae61a427fcb02d3edee8f"
>>>>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>>>
>>>>   SRC_URI =
>>>> 
>>>>"git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${K
>>>>B
>>>>RANCH},meta;name=machine,meta"
>>>>
>>>> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>>>> b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>>>> index 6defed1c9464..a852f75ff443 100644
>>>> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>>>> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>>>> @@ -9,7 +9,7 @@ LINUX_VERSION ?= "3.10.25"
>>>>
>>>>   KMETA = "meta"
>>>>
>>>> -SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>>>> +SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>>>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>>>
>>>>   PV = "${LINUX_VERSION}+git${SRCPV}"
>>>> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>>>> b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>>>> index d0772fddc5f1..f7f4dabea8d5 100644
>>>> --- a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>>>> +++ b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>>>> @@ -11,13 +11,13 @@ KBRANCH_qemux86  = "standard/common-pc/base"
>>>>   KBRANCH_qemux86-64  = "standard/common-pc-64/base"
>>>>   KBRANCH_qemumips64 = "standard/mti-malta64"
>>>>
>>>> -SRCREV_machine_qemuarm ?= "e3163012f3e09fe48374ef22bc676f8b19aeec1a"
>>>> -SRCREV_machine_qemumips ?= "01a71aaf8e545c3ef88da1fe02f53d1b96a2640e"
>>>> -SRCREV_machine_qemuppc ?= "ae1b9115975ff235038d5da22b4cc984b4d76aae"
>>>> -SRCREV_machine_qemux86 ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>>>> -SRCREV_machine_qemux86-64 ?=
>>>>"79af968f2f26378798aec7a6d729ff5a371aae5f"
>>>> -SRCREV_machine_qemumips64 ?=
>>>>"67efb2993ec7726df5567e2572fd64e34e29b46d"
>>>> -SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>>>> +SRCREV_machine_qemuarm ?= "2a4d8c0884c8d08896c052a6e42c51e861cf48b5"
>>>> +SRCREV_machine_qemumips ?= "08872a160571b9bf45b6cd262b977063f12aca46"
>>>> +SRCREV_machine_qemuppc ?= "eba0c4fcc962ffddd384251b5b6ee0c61bd5ea4d"
>>>> +SRCREV_machine_qemux86 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>>> +SRCREV_machine_qemux86-64 ?=
>>>>"78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>>> +SRCREV_machine_qemumips64 ?=
>>>>"de555074575d2997a8cd7a4b2d6dbf22e7ddfc9b"
>>>> +SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>>>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>>>
>>>>   SRC_URI =
>>>> 
>>>>"git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${K
>>>>B
>>>>RANCH},${KMETA};name=machine,meta"
>>>>
>>>>
>>>
>>> This change seems to have introduced an issue with the x86* builds as
>>
>>Adding Darren, since qemux86 builds just fine. We'll need his eyes on
>>the actual failure and fix.
>>
>>Bruce
>>
>>> follows:
>>>> | drivers/built-in.o: In function `gen6_update_ring_freq':
>>>> |
>>>> 
>>>>/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/bui
>>>>l
>>>>d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580
>>>>_
>>>>78d2a615b1-r0/linux/drivers/gpu/drm/i915/intel_pm.c:3876:
>>>> undefined reference to `cpufreq_cpu_get'
>>>> |
>>>> 
>>>>/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/bui
>>>>l
>>>>d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580
>>>>_
>>>>78d2a615b1-r0/linux/drivers/gpu/drm/i915/intel_pm.c:3879:
>>>> undefined reference to `cpufreq_cpu_put'
>>>> | make[2]: *** [vmlinux] Error 1
>>>> | make[1]: *** [sub-make] Error 2
>>>> | make: *** [all] Error 2
>>>> | ERROR: oe_runmake failed
>>>> | WARNING:
>>>> 
>>>>/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/bui
>>>>l
>>>>d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580
>>>>_
>>>>78d2a615b1-r0/temp/run.do_compile.1426:1
>>>> exit 1 from
>>>> |   exit 1
>>>> | ERROR: Function failed: do_compile (log file is located at
>>>> 
>>>>/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/bui
>>>>l
>>>>d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580
>>>>_
>>>>78d2a615b1-r0/temp/log.do_compile.1426)
>>>>
>>>> NOTE: recipe linux-yocto-3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0:
>>>> task do_compile: Failed
>>>> ERROR: Task 149
>>>> 
>>>>(/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/me
>>>>t
>>>>a/recipes-kernel/linux/linux-yocto_3.10.bb,
>>>> do_compile) failed with exit code '1'
>>>> NOTE: recipe gcc-runtime-4.8.2-r0: task do_compile: Succeeded
>>>
>>> This can be seen on the AB
>>> 
>>>http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/20/
>>>s
>>>teps/BuildImages/logs/stdio
>>>
>>>
>>> This is one example.
>>>
>>> Thanks
>>>      Sau!
>>>
>>>
>>
>>
>
>

Re: [PATCH 2/2] linux-yocto/3.10: integrate LTSI

[Bruce Ashfield]

On 14-02-07 11:47 AM, Darren Hart wrote:
> Erm, and Nitin Cc'd this time. Sigh. Always a hoot.\

:). I've booted all the qemu boards, so the general code is sane. But
obviously there's a config in here that is hitting a bad merge, or just
a condition that is otherwise not exercised by qemu.

I'm starting my own builds as well, but wanted more eyes on things.

Bruce

>
> On 2/7/14, 8:46, "Darren Hart" <dvhart@linux.intel.com> wrote:
>
>> Nitin - please join me in looking into what's happening here.
>>
>> On 2/7/14, 8:44, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
>>
>>> On 14-02-07 11:42 AM, Saul Wold wrote:
>>>> On 02/04/2014 09:34 AM, Bruce Ashfield wrote:
>>>>> Updating the SRCREVs of the 3.10 tree to reflect the integration of
>>>>> of commit 68054859 from:
>>>>>
>>>>>
>>>>>
>>>>> git://git.linuxfoundation.org/ltsi-kernegit://git.linuxfoundation.org/l
>>>>> t
>>>>> si-kernel.git
>>>>>
>>>>>
>>>>> Build and boot tested on all qemu architectures.
>>>>>
>>>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>>>>> ---
>>>>>    meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb   |  4 ++--
>>>>>    meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb |  2 +-
>>>>>    meta/recipes-kernel/linux/linux-yocto_3.10.bb      | 14
>>>>> +++++++-------
>>>>>    3 files changed, 10 insertions(+), 10 deletions(-)
>>>>>
>>>>> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>>>>> b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>>>>> index 9bdd47ecbf65..dd1ec52626d1 100644
>>>>> --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>>>>> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>>>>> @@ -3,8 +3,8 @@ require recipes-kernel/linux/linux-yocto.inc
>>>>>    KBRANCH = "standard/preempt-rt/base"
>>>>>    KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
>>>>>
>>>>> -SRCREV_machine ?= "957ba6ae6c1d81b57da6a36b93f1b2a0ced2f45d"
>>>>> -SRCREV_machine_qemuppc ?= "37e40b7017a9c78d676b19716011494dc7cb6369"
>>>>> +SRCREV_machine ?= "14651317755a87f03f8399299f2eb0b4042a2d0c"
>>>>> +SRCREV_machine_qemuppc ?= "2918b5d9ee82304d67aae61a427fcb02d3edee8f"
>>>>>    SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>>>>
>>>>>    SRC_URI =
>>>>>
>>>>> "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${K
>>>>> B
>>>>> RANCH},meta;name=machine,meta"
>>>>>
>>>>> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>>>>> b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>>>>> index 6defed1c9464..a852f75ff443 100644
>>>>> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>>>>> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>>>>> @@ -9,7 +9,7 @@ LINUX_VERSION ?= "3.10.25"
>>>>>
>>>>>    KMETA = "meta"
>>>>>
>>>>> -SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>>>>> +SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>>>>    SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>>>>
>>>>>    PV = "${LINUX_VERSION}+git${SRCPV}"
>>>>> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>>>>> b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>>>>> index d0772fddc5f1..f7f4dabea8d5 100644
>>>>> --- a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>>>>> +++ b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>>>>> @@ -11,13 +11,13 @@ KBRANCH_qemux86  = "standard/common-pc/base"
>>>>>    KBRANCH_qemux86-64  = "standard/common-pc-64/base"
>>>>>    KBRANCH_qemumips64 = "standard/mti-malta64"
>>>>>
>>>>> -SRCREV_machine_qemuarm ?= "e3163012f3e09fe48374ef22bc676f8b19aeec1a"
>>>>> -SRCREV_machine_qemumips ?= "01a71aaf8e545c3ef88da1fe02f53d1b96a2640e"
>>>>> -SRCREV_machine_qemuppc ?= "ae1b9115975ff235038d5da22b4cc984b4d76aae"
>>>>> -SRCREV_machine_qemux86 ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>>>>> -SRCREV_machine_qemux86-64 ?=
>>>>> "79af968f2f26378798aec7a6d729ff5a371aae5f"
>>>>> -SRCREV_machine_qemumips64 ?=
>>>>> "67efb2993ec7726df5567e2572fd64e34e29b46d"
>>>>> -SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>>>>> +SRCREV_machine_qemuarm ?= "2a4d8c0884c8d08896c052a6e42c51e861cf48b5"
>>>>> +SRCREV_machine_qemumips ?= "08872a160571b9bf45b6cd262b977063f12aca46"
>>>>> +SRCREV_machine_qemuppc ?= "eba0c4fcc962ffddd384251b5b6ee0c61bd5ea4d"
>>>>> +SRCREV_machine_qemux86 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>>>> +SRCREV_machine_qemux86-64 ?=
>>>>> "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>>>> +SRCREV_machine_qemumips64 ?=
>>>>> "de555074575d2997a8cd7a4b2d6dbf22e7ddfc9b"
>>>>> +SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>>>>    SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>>>>
>>>>>    SRC_URI =
>>>>>
>>>>> "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${K
>>>>> B
>>>>> RANCH},${KMETA};name=machine,meta"
>>>>>
>>>>>
>>>>
>>>> This change seems to have introduced an issue with the x86* builds as
>>>
>>> Adding Darren, since qemux86 builds just fine. We'll need his eyes on
>>> the actual failure and fix.
>>>
>>> Bruce
>>>
>>>> follows:
>>>>> | drivers/built-in.o: In function `gen6_update_ring_freq':
>>>>> |
>>>>>
>>>>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/bui
>>>>> l
>>>>> d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580
>>>>> _
>>>>> 78d2a615b1-r0/linux/drivers/gpu/drm/i915/intel_pm.c:3876:
>>>>> undefined reference to `cpufreq_cpu_get'
>>>>> |
>>>>>
>>>>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/bui
>>>>> l
>>>>> d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580
>>>>> _
>>>>> 78d2a615b1-r0/linux/drivers/gpu/drm/i915/intel_pm.c:3879:
>>>>> undefined reference to `cpufreq_cpu_put'
>>>>> | make[2]: *** [vmlinux] Error 1
>>>>> | make[1]: *** [sub-make] Error 2
>>>>> | make: *** [all] Error 2
>>>>> | ERROR: oe_runmake failed
>>>>> | WARNING:
>>>>>
>>>>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/bui
>>>>> l
>>>>> d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580
>>>>> _
>>>>> 78d2a615b1-r0/temp/run.do_compile.1426:1
>>>>> exit 1 from
>>>>> |   exit 1
>>>>> | ERROR: Function failed: do_compile (log file is located at
>>>>>
>>>>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/bui
>>>>> l
>>>>> d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580
>>>>> _
>>>>> 78d2a615b1-r0/temp/log.do_compile.1426)
>>>>>
>>>>> NOTE: recipe linux-yocto-3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0:
>>>>> task do_compile: Failed
>>>>> ERROR: Task 149
>>>>>
>>>>> (/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/me
>>>>> t
>>>>> a/recipes-kernel/linux/linux-yocto_3.10.bb,
>>>>> do_compile) failed with exit code '1'
>>>>> NOTE: recipe gcc-runtime-4.8.2-r0: task do_compile: Succeeded
>>>>
>>>> This can be seen on the AB
>>>>
>>>> http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/20/
>>>> s
>>>> teps/BuildImages/logs/stdio
>>>>
>>>>
>>>> This is one example.
>>>>
>>>> Thanks
>>>>       Sau!
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>

Re: [PATCH 2/2] linux-yocto/3.10: integrate LTSI

[Darren Hart]

On 2/7/14, 8:48, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
>>>>>>| ERROR: Function failed: do_compile (log file is located at
>>>>>>
>>>>>> 
>>>>>>/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/b
>>>>>>ui
>>>>>> l
>>>>>> 
>>>>>>d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa5
>>>>>>80
>>>>>> _
>>>>>> 78d2a615b1-r0/temp/log.do_compile.1426)

So since this is qemux86 that is failing, and Bruce has run the qemu
builds - so are we using the right SRCREVs?

Machine: 78d2a615b1
Meta: 4d658aa580

>>>>>
>>>>> This can be seen on the AB
>>>>>
>>>>> 
>>>>>http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/2
>>>>>0/
>>>>> s
>>>>> teps/BuildImages/logs/stdio

--
Darren

Re: [PATCH 2/2] linux-yocto/3.10: integrate LTSI

[Bruce Ashfield]

On 14-02-07 11:55 AM, Darren Hart wrote:
> On 2/7/14, 8:48, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
>>>>>>> | ERROR: Function failed: do_compile (log file is located at
>>>>>>>
>>>>>>>
>>>>>>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/b
>>>>>>> ui
>>>>>>> l
>>>>>>>
>>>>>>> d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa5
>>>>>>> 80
>>>>>>> _
>>>>>>> 78d2a615b1-r0/temp/log.do_compile.1426)
>
> So since this is qemux86 that is failing, and Bruce has run the qemu
> builds - so are we using the right SRCREVs?
>
> Machine: 78d2a615b1
> Meta: 4d658aa580

That's exactly what just popped into my mind. I didn't send updates
for the meta-yocto BSPs with this first change. But the old SRCREVs
should have continued to work .. very odd, I did see generic x86
in the path, so I thought it was something different.

Bruce

>
>>>>>>
>>>>>> This can be seen on the AB
>>>>>>
>>>>>>
>>>>>> http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/2
>>>>>> 0/
>>>>>> s
>>>>>> teps/BuildImages/logs/stdio
>
> --
> Darren
>
>

Re: [PATCH 2/2] linux-yocto/3.10: integrate LTSI

[Bruce Ashfield]

On 14-02-07 11:55 AM, Darren Hart wrote:
> On 2/7/14, 8:48, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
>>>>>>> | ERROR: Function failed: do_compile (log file is located at
>>>>>>>
>>>>>>>
>>>>>>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/b
>>>>>>> ui
>>>>>>> l
>>>>>>>
>>>>>>> d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa5
>>>>>>> 80
>>>>>>> _
>>>>>>> 78d2a615b1-r0/temp/log.do_compile.1426)
>
> So since this is qemux86 that is failing, and Bruce has run the qemu
> builds - so are we using the right SRCREVs?
>
> Machine: 78d2a615b1
> Meta: 4d658aa580

Sorry for the spam, but is this the same issue that Nitin' fixed
upstream that that I integrated this week ? I have another pending
commit that updates the SRCREVs again, but I was waiting on LTSI to
make it in before sending it.

Bruce

>
>>>>>>
>>>>>> This can be seen on the AB
>>>>>>
>>>>>>
>>>>>> http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/2
>>>>>> 0/
>>>>>> s
>>>>>> teps/BuildImages/logs/stdio
>
> --
> Darren
>
>

Re: [PATCH 2/2] linux-yocto/3.10: integrate LTSI

[Darren Hart]

On 2/7/14, 9:24, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:

>On 14-02-07 11:55 AM, Darren Hart wrote:
>> On 2/7/14, 8:48, "Bruce Ashfield" <bruce.ashfield@windriver.com> wrote:
>>>>>>>> | ERROR: Function failed: do_compile (log file is located at
>>>>>>>>
>>>>>>>>
>>>>>>>> 
>>>>>>>>/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build
>>>>>>>>/b
>>>>>>>> ui
>>>>>>>> l
>>>>>>>>
>>>>>>>> 
>>>>>>>>d/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658a
>>>>>>>>a5
>>>>>>>> 80
>>>>>>>> _
>>>>>>>> 78d2a615b1-r0/temp/log.do_compile.1426)
>>
>> So since this is qemux86 that is failing, and Bruce has run the qemu
>> builds - so are we using the right SRCREVs?
>>
>> Machine: 78d2a615b1
>> Meta: 4d658aa580
>
>Sorry for the spam, but is this the same issue that Nitin' fixed
>upstream that that I integrated this week ? I have another pending
>commit that updates the SRCREVs again, but I was waiting on LTSI to
>make it in before sending it.

No, this is failing with:

| drivers/built-in.o: In function `gen6_update_ring_freq':
| 
/build/yocto/master/qemux86_20140207091321/build/tmp/work/qemux86-poky-linu
x/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/linux/drivers/gpu
/drm/i915/intel_pm.c:3876: undefined reference to `cpufreq_cpu_get'
| 
/build/yocto/master/qemux86_20140207091321/build/tmp/work/qemux86-poky-linu
x/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/linux/drivers/gpu
/drm/i915/intel_pm.c:3879: undefined reference to `cpufreq_cpu_put'


The Kconfig fix from Nitin was for generic_chip.c, this is for i915 and pm.

I'll update SRCREVs and see if this resolves itself.

--
Darren

Re: [PATCH 2/2] linux-yocto/3.10: integrate LTSI

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 5900 bytes --]

The 32 bit qemu BSP needs powermanagement .. it's a kernel bug, but
can fix it via a config change.

I've attached the fix.

Bruce

On 14-02-07 11:42 AM, Saul Wold wrote:
> On 02/04/2014 09:34 AM, Bruce Ashfield wrote:
>> Updating the SRCREVs of the 3.10 tree to reflect the integration of
>> of commit 68054859 from:
>>
>>
>> git://git.linuxfoundation.org/ltsi-kernegit://git.linuxfoundation.org/ltsi-kernel.git
>>
>>
>> Build and boot tested on all qemu architectures.
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>>   meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb   |  4 ++--
>>   meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb |  2 +-
>>   meta/recipes-kernel/linux/linux-yocto_3.10.bb      | 14 +++++++-------
>>   3 files changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>> b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>> index 9bdd47ecbf65..dd1ec52626d1 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
>> @@ -3,8 +3,8 @@ require recipes-kernel/linux/linux-yocto.inc
>>   KBRANCH = "standard/preempt-rt/base"
>>   KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
>>
>> -SRCREV_machine ?= "957ba6ae6c1d81b57da6a36b93f1b2a0ced2f45d"
>> -SRCREV_machine_qemuppc ?= "37e40b7017a9c78d676b19716011494dc7cb6369"
>> +SRCREV_machine ?= "14651317755a87f03f8399299f2eb0b4042a2d0c"
>> +SRCREV_machine_qemuppc ?= "2918b5d9ee82304d67aae61a427fcb02d3edee8f"
>>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>
>>   SRC_URI =
>> "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
>>
>> diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>> b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>> index 6defed1c9464..a852f75ff443 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
>> @@ -9,7 +9,7 @@ LINUX_VERSION ?= "3.10.25"
>>
>>   KMETA = "meta"
>>
>> -SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>> +SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>
>>   PV = "${LINUX_VERSION}+git${SRCPV}"
>> diff --git a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>> b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>> index d0772fddc5f1..f7f4dabea8d5 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
>> @@ -11,13 +11,13 @@ KBRANCH_qemux86  = "standard/common-pc/base"
>>   KBRANCH_qemux86-64  = "standard/common-pc-64/base"
>>   KBRANCH_qemumips64 = "standard/mti-malta64"
>>
>> -SRCREV_machine_qemuarm ?= "e3163012f3e09fe48374ef22bc676f8b19aeec1a"
>> -SRCREV_machine_qemumips ?= "01a71aaf8e545c3ef88da1fe02f53d1b96a2640e"
>> -SRCREV_machine_qemuppc ?= "ae1b9115975ff235038d5da22b4cc984b4d76aae"
>> -SRCREV_machine_qemux86 ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>> -SRCREV_machine_qemux86-64 ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>> -SRCREV_machine_qemumips64 ?= "67efb2993ec7726df5567e2572fd64e34e29b46d"
>> -SRCREV_machine ?= "79af968f2f26378798aec7a6d729ff5a371aae5f"
>> +SRCREV_machine_qemuarm ?= "2a4d8c0884c8d08896c052a6e42c51e861cf48b5"
>> +SRCREV_machine_qemumips ?= "08872a160571b9bf45b6cd262b977063f12aca46"
>> +SRCREV_machine_qemuppc ?= "eba0c4fcc962ffddd384251b5b6ee0c61bd5ea4d"
>> +SRCREV_machine_qemux86 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>> +SRCREV_machine_qemux86-64 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>> +SRCREV_machine_qemumips64 ?= "de555074575d2997a8cd7a4b2d6dbf22e7ddfc9b"
>> +SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
>>   SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
>>
>>   SRC_URI =
>> "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
>>
>>
>
> This change seems to have introduced an issue with the x86* builds as
> follows:
>> | drivers/built-in.o: In function `gen6_update_ring_freq':
>> |
>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/build/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/linux/drivers/gpu/drm/i915/intel_pm.c:3876:
>> undefined reference to `cpufreq_cpu_get'
>> |
>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/build/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/linux/drivers/gpu/drm/i915/intel_pm.c:3879:
>> undefined reference to `cpufreq_cpu_put'
>> | make[2]: *** [vmlinux] Error 1
>> | make[1]: *** [sub-make] Error 2
>> | make: *** [all] Error 2
>> | ERROR: oe_runmake failed
>> | WARNING:
>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/build/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/temp/run.do_compile.1426:1
>> exit 1 from
>> |   exit 1
>> | ERROR: Function failed: do_compile (log file is located at
>> /home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/build/tmp/work/qemux86-poky-linux/linux-yocto/3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0/temp/log.do_compile.1426)
>>
>> NOTE: recipe linux-yocto-3.10.25+gitAUTOINC+4d658aa580_78d2a615b1-r0:
>> task do_compile: Failed
>> ERROR: Task 149
>> (/home/pokybuild/yocto-autobuilder-dev/yocto-slave/nightly-x86/build/meta/recipes-kernel/linux/linux-yocto_3.10.bb,
>> do_compile) failed with exit code '1'
>> NOTE: recipe gcc-runtime-4.8.2-r0: task do_compile: Succeeded
>
> This can be seen on the AB
> http://autobuilder.yoctoproject.org/main/builders/nightly-x86/builds/20/steps/BuildImages/logs/stdio
>
>
> This is one example.
>
> Thanks
>      Sau!
>
>


[-- Attachment #2: 0001-linux-yocto-3.10-add-powermanagement-config-to-32-bi.patch --]
[-- Type: text/x-patch, Size: 2825 bytes --]

From 3826d38f8e8fc9a98b321bfda6d8bdfedb26be12 Mon Sep 17 00:00:00 2001
From: Bruce Ashfield <bruce.ashfield@windriver.com>
Date: Fri, 7 Feb 2014 14:04:51 -0500
Subject: [PATCH] linux-yocto/3.10: add powermanagement config to 32 bit
 common-pc

The introduction of LTSI has exposed a missing dependency on cpufreq
being enabled. To fix the build, we enable power management in the
32 bit BSP, which aligns it with 64 bit.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb   | 2 +-
 meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_3.10.bb      | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
index dd1ec52626d1..fa6415aa4f42 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.10.bb
@@ -5,7 +5,7 @@ KBRANCH_qemuppc = "standard/preempt-rt/qemuppc"
 
 SRCREV_machine ?= "14651317755a87f03f8399299f2eb0b4042a2d0c"
 SRCREV_machine_qemuppc ?= "2918b5d9ee82304d67aae61a427fcb02d3edee8f"
-SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
+SRCREV_meta ?= "713abc0efa9fc21234b2f342d0a849e4a4a36c65"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
index a852f75ff443..923f9123322b 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.10.bb
@@ -10,7 +10,7 @@ LINUX_VERSION ?= "3.10.25"
 KMETA = "meta"
 
 SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
-SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
+SRCREV_meta ?= "713abc0efa9fc21234b2f342d0a849e4a4a36c65"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.10.bb b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
index f7f4dabea8d5..8b90d6b5ed5d 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.10.bb
@@ -18,7 +18,7 @@ SRCREV_machine_qemux86 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
 SRCREV_machine_qemux86-64 ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
 SRCREV_machine_qemumips64 ?= "de555074575d2997a8cd7a4b2d6dbf22e7ddfc9b"
 SRCREV_machine ?= "78d2a615b13a1c307d482eaa9499c1b2dee40599"
-SRCREV_meta ?= "4d658aa580df62232a4a84957b02496436dc17c4"
+SRCREV_meta ?= "713abc0efa9fc21234b2f342d0a849e4a4a36c65"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.10.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
 
-- 
1.8.1.2