Patch failures

Patch failures

[Paul D. DeRocco]

I'm trying to migrate an Atom-based build from Fido to Morty, and also
switch from 32-bit mode to x32. On a clean build, it gets about half way
through, and then suddenly coughs up a patch error. I've put blank lines
between the log lines so that the email word wrap won't be as confusing:

--

DEBUG: Executing shell function do_patch

(1/660) ARM-LPAE-Invalidate-the-TLB-for-module-addresses-dur.patch

[INFO]: check of
.kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate-the-TLB-for-mod
ule-addresses-dur.patch with "git am" did not pass, trying reduced
context.

[INFO]: Context reduced git-am of
.kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate-the-TLB-for-mod
ule-addresses-dur.patch with "git am" did not work, trying "apply".

error: patch failed: arch/arm/mm/fault.c:448

error: arch/arm/mm/fault.c: patch does not apply

[ERROR]: Application of
.kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate-
the-TLB-for-module-addresses-dur.patch failed.

         Patch needs to be refreshed. Sample resolution script:

             .git/rebase-apply/resolve_rejects

WARNING:
/home/pauld/yocto-morty/build/tmp/work/chroma_bsp-poky-linux-gnux32/linux-
yocto-rt/4.8.12+gitAUTOINC+926c93ae07_3bafd55e39-r0/temp/run.do_patch.3069
0:1 exit 1 from 'kgit-s2q --gen -v --patches .kernel-meta/'

ERROR: Function failed: do_patch (log file is located at
/home/pauld/yocto-morty/build/tmp/work/chroma_bsp-poky-linux-gnux32/linux-
yocto-rt/4.8.12+gitAUTOINC+926c93ae07_3bafd55e39-r0/temp/log.do_patch.3069
0)

--

If I start bitbake again, it detects a "fence", and proceeds a little
further. I can do it over and over again, and it keeps building more and
more, but this can't be right, can it? The strange thing is that the
patches are all about ARM, PowerPC, etc., which have nothing to do with my
system. Could this be some fundamental misconfiguration having to do with
my MACHINE? At the beginning of my local.conf, I have:

	MACHINE ?= "chroma-bsp"
	DEFAULTTUNE = "core2-64-x32"
	baselib = "libx32"

where chroma-bsp is defined in my own layer. My chroma-bsp.conf file
contains (among other things):

	PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-rt"
	PREFERRED_VERSION_linux-yocto-rt ?= "4.8%"
	require conf/machine/include/tune-atom.inc
	require conf/machine/include/x86-base.inc

I'm not really good at this. Does anyone see anything wrong?

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

Re: Patch failures

[Khem Raj]

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

What's your build OS

On Sun, Apr 16, 2017 at 6:09 PM Paul D. DeRocco <pderocco@ix.netcom.com>
wrote:

> I'm trying to migrate an Atom-based build from Fido to Morty, and also
> switch from 32-bit mode to x32. On a clean build, it gets about half way
> through, and then suddenly coughs up a patch error. I've put blank lines
> between the log lines so that the email word wrap won't be as confusing:
>
> --
>
> DEBUG: Executing shell function do_patch
>
> (1/660) ARM-LPAE-Invalidate-the-TLB-for-module-addresses-dur.patch
>
> [INFO]: check of
> .kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate-the-TLB-for-mod
> ule-addresses-dur.patch with "git am" did not pass, trying reduced
> context.
>
> [INFO]: Context reduced git-am of
> .kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate-the-TLB-for-mod
> ule-addresses-dur.patch with "git am" did not work, trying "apply".
>
> error: patch failed: arch/arm/mm/fault.c:448
>
> error: arch/arm/mm/fault.c: patch does not apply
>
> [ERROR]: Application of
> .kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate-
> the-TLB-for-module-addresses-dur.patch failed.
>
>          Patch needs to be refreshed. Sample resolution script:
>
>              .git/rebase-apply/resolve_rejects
>
> WARNING:
> /home/pauld/yocto-morty/build/tmp/work/chroma_bsp-poky-linux-gnux32/linux-
> yocto-rt/4.8.12+gitAUTOINC+926c93ae07_3bafd55e39-r0/temp/run.do_patch.3069
> 0:1 exit 1 from 'kgit-s2q --gen -v --patches .kernel-meta/'
>
> ERROR: Function failed: do_patch (log file is located at
> /home/pauld/yocto-morty/build/tmp/work/chroma_bsp-poky-linux-gnux32/linux-
> yocto-rt/4.8.12+gitAUTOINC+926c93ae07_3bafd55e39-r0/temp/log.do_patch.3069
> 0)
>
> --
>
> If I start bitbake again, it detects a "fence", and proceeds a little
> further. I can do it over and over again, and it keeps building more and
> more, but this can't be right, can it? The strange thing is that the
> patches are all about ARM, PowerPC, etc., which have nothing to do with my
> system. Could this be some fundamental misconfiguration having to do with
> my MACHINE? At the beginning of my local.conf, I have:
>
>         MACHINE ?= "chroma-bsp"
>         DEFAULTTUNE = "core2-64-x32"
>         baselib = "libx32"
>
> where chroma-bsp is defined in my own layer. My chroma-bsp.conf file
> contains (among other things):
>
>         PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-rt"
>         PREFERRED_VERSION_linux-yocto-rt ?= "4.8%"
>         require conf/machine/include/tune-atom.inc
>         require conf/machine/include/x86-base.inc
>
> I'm not really good at this. Does anyone see anything wrong?
>
> --
>
> Ciao,               Paul D. DeRocco
> Paul                mailto:pderocco@ix.netcom.com
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

[-- Attachment #2: Type: text/html, Size: 3754 bytes --]

Re: Patch failures

[Bruce Ashfield]

On 2017-04-16 7:43 PM, Paul D. DeRocco wrote:
> I'm trying to migrate an Atom-based build from Fido to Morty, and also
> switch from 32-bit mode to x32. On a clean build, it gets about half way
> through, and then suddenly coughs up a patch error. I've put blank lines
> between the log lines so that the email word wrap won't be as confusing:
>
> --
>
> DEBUG: Executing shell function do_patch
>
> (1/660) ARM-LPAE-Invalidate-the-TLB-for-module-addresses-dur.patch
>
> [INFO]: check of
> .kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate-the-TLB-for-mod
> ule-addresses-dur.patch with "git am" did not pass, trying reduced
> context.
>
> [INFO]: Context reduced git-am of
> .kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate-the-TLB-for-mod
> ule-addresses-dur.patch with "git am" did not work, trying "apply".
>
> error: patch failed: arch/arm/mm/fault.c:448
>
> error: arch/arm/mm/fault.c: patch does not apply
>
> [ERROR]: Application of
> .kernel-meta//patches//arch/arm/v7-A15/ARM-LPAE-Invalidate-
> the-TLB-for-module-addresses-dur.patch failed.
>
>          Patch needs to be refreshed. Sample resolution script:
>
>              .git/rebase-apply/resolve_rejects
>
> WARNING:
> /home/pauld/yocto-morty/build/tmp/work/chroma_bsp-poky-linux-gnux32/linux-
> yocto-rt/4.8.12+gitAUTOINC+926c93ae07_3bafd55e39-r0/temp/run.do_patch.3069
> 0:1 exit 1 from 'kgit-s2q --gen -v --patches .kernel-meta/'
>
> ERROR: Function failed: do_patch (log file is located at
> /home/pauld/yocto-morty/build/tmp/work/chroma_bsp-poky-linux-gnux32/linux-
> yocto-rt/4.8.12+gitAUTOINC+926c93ae07_3bafd55e39-r0/temp/log.do_patch.3069
> 0)
>
> --
>
> If I start bitbake again, it detects a "fence", and proceeds a little
> further. I can do it over and over again, and it keeps building more and
> more, but this can't be right, can it? The strange thing is that the
> patches are all about ARM, PowerPC, etc., which have nothing to do with my
> system. Could this be some fundamental misconfiguration having to do with
> my MACHINE? At the beginning of my local.conf, I have:

The content of the patches isn't relative. All the patches are applied
all the time. Doing arch specific patches in a large patch queue turns
into a dependency soup ... hence the entire linux-yocto queue is
checked against the build branch on each build, and if something is
missing, patches are pushed.

What that sounds like is that your BSP doesn't have a proper definition
and hence entry point to the patching process. As such, whatever branch
is being built doesn't have the patches applied .. and hence the patches
are pushed and fail to apply in your context.

I can't say from what you've provided why the BSP description isn't
valid, but if the kernel recipe and layers are something I can look at,
I can debug more.

There were some changes between those releases that tweaked the kernel
meta-data processing .. and that could be the issue, but again, I can't
say without seeing all the details.

Bruce

>
> 	MACHINE ?= "chroma-bsp"
> 	DEFAULTTUNE = "core2-64-x32"
> 	baselib = "libx32"
>
> where chroma-bsp is defined in my own layer. My chroma-bsp.conf file
> contains (among other things):
>
> 	PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-rt"
> 	PREFERRED_VERSION_linux-yocto-rt ?= "4.8%"
> 	require conf/machine/include/tune-atom.inc
> 	require conf/machine/include/x86-base.inc
>
> I'm not really good at this. Does anyone see anything wrong?
>

Re: Patch failures

[Paul D. DeRocco]

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

> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com] 
> 
> I can't say from what you've provided why the BSP description isn't
> valid, but if the kernel recipe and layers are something I 
> can look at,
> I can debug more.
> 
> There were some changes between those releases that tweaked the kernel
> meta-data processing .. and that could be the issue, but 
> again, I can't
> say without seeing all the details.

I've attached a zip containing the stuff I've added. It also includes the
log file showing the patch errors. It also shows a log of a few thousand
identical errors from grub-efi, having to do with a 32 vs 64 mismatch. In
the past, my system has always booted via Syslinux, not Grub, so I don't
know what changed between Fido and Morty, or if Syslinux doesn't support
64-bit booting. So there's another unrelated question.

The history is this: I originally developed this as a 32-bit OS under
Danny, then updated it with no problems to Fido. I wanted to try the x32
ABI, since the extra registers could be very useful (lots of SSE SIMD in
the application). Perhaps I should have first tried updating to Morty
without x32. I had to change some version numbers (the kernel, systemd,
Samba), and of course add the x32 tune. For Samba, I added a few layers
from OE.

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com

[-- Attachment #2: foo.zip --]
[-- Type: application/x-zip-compressed, Size: 44649 bytes --]

Re: Patch failures

[Bruce Ashfield]

On 2017-04-17 2:18 AM, Paul D. DeRocco wrote:
>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>>
>> I can't say from what you've provided why the BSP description isn't
>> valid, but if the kernel recipe and layers are something I
>> can look at,
>> I can debug more.
>>
>> There were some changes between those releases that tweaked the kernel
>> meta-data processing .. and that could be the issue, but
>> again, I can't
>> say without seeing all the details.
>
> I've attached a zip containing the stuff I've added. It also includes the
> log file showing the patch errors. It also shows a log of a few thousand
> identical errors from grub-efi, having to do with a 32 vs 64 mismatch. In
> the past, my system has always booted via Syslinux, not Grub, so I don't
> know what changed between Fido and Morty, or if Syslinux doesn't support
> 64-bit booting. So there's another unrelated question.
>

I finally got a chance to look at the layers, and I can see that the
processing code would in fact pick/generate a generic board description
and that could lead you into the failures you are seeing.

I assume you are building for MACHINE="chroma-bsp" and the linux-yocto-rt
kernel recipe ?

If you can confirm the details, and anything else, I can mock up a
recipe space BSP description that should work.

Bruce

> The history is this: I originally developed this as a 32-bit OS under
> Danny, then updated it with no problems to Fido. I wanted to try the x32
> ABI, since the extra registers could be very useful (lots of SSE SIMD in
> the application). Perhaps I should have first tried updating to Morty
> without x32. I had to change some version numbers (the kernel, systemd,
> Samba), and of course add the x32 tune. For Samba, I added a few layers
> from OE.
>

Re: Patch failures

[Bruce Ashfield]

On 2017-04-19 12:24 PM, Bruce Ashfield wrote:
> On 2017-04-17 2:18 AM, Paul D. DeRocco wrote:
>>> From: Bruce Ashfield [mailto:bruce.ashfield@windriver.com]
>>>
>>> I can't say from what you've provided why the BSP description isn't
>>> valid, but if the kernel recipe and layers are something I
>>> can look at,
>>> I can debug more.
>>>
>>> There were some changes between those releases that tweaked the kernel
>>> meta-data processing .. and that could be the issue, but
>>> again, I can't
>>> say without seeing all the details.
>>
>> I've attached a zip containing the stuff I've added. It also includes the
>> log file showing the patch errors. It also shows a log of a few thousand
>> identical errors from grub-efi, having to do with a 32 vs 64 mismatch. In
>> the past, my system has always booted via Syslinux, not Grub, so I don't
>> know what changed between Fido and Morty, or if Syslinux doesn't support
>> 64-bit booting. So there's another unrelated question.
>>
>
> I finally got a chance to look at the layers, and I can see that the
> processing code would in fact pick/generate a generic board description
> and that could lead you into the failures you are seeing.
>
> I assume you are building for MACHINE="chroma-bsp" and the linux-yocto-rt
> kernel recipe ?
>
> If you can confirm the details, and anything else, I can mock up a
> recipe space BSP description that should work.

I take that back. After debugging, I see that you did have a recipe
space BSP definition, and it is in fact being picked up.

What you are seeing is an optimization and simplification in the way
that patches are processed (that I introduced in morty). That
simplication is:

   - if a patch is listed on the SRC_URI or in a .scc on the SRC_URI
     it is always applied.

Sounds simple, since it is. And that replaced the logic that was capable
of looking into a patch queue, comparing it to the branch being built
and would determine if anything needed to be pushed by walking the
commits. That process was slow, and error prone, since similarly named
commits could trigger an early start to patching and hence a patch
failure that wasn't easy to catch.

Since your BSP definition is on the SRC_URI, and is including the
preempt-rt kernel type, the rule I stated above applies and it tries
to (re)push all the patches.

The fix is simple, change the line to this:

   include ktypes/preempt-rt/preempt-rt.scc nopatch

And you'll inherit the preempt-rt branch + configurations, but not
the patches.

Honestly, I can't say if that was documented, so I'll go dig around
and see if it was.

Cheers,

Bruce

>
> Bruce
>
>> The history is this: I originally developed this as a 32-bit OS under
>> Danny, then updated it with no problems to Fido. I wanted to try the x32
>> ABI, since the extra registers could be very useful (lots of SSE SIMD in
>> the application). Perhaps I should have first tried updating to Morty
>> without x32. I had to change some version numbers (the kernel, systemd,
>> Samba), and of course add the x32 tune. For Samba, I added a few layers
>> from OE.
>>
>