[yocto] 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?
>