* Patch failures
@ 2017-04-16 23:43 Paul D. DeRocco
2017-04-17 2:01 ` Khem Raj
2017-04-17 3:08 ` Bruce Ashfield
0 siblings, 2 replies; 6+ messages in thread
From: Paul D. DeRocco @ 2017-04-16 23:43 UTC (permalink / raw)
To: yocto
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Patch failures 2017-04-16 23:43 Patch failures Paul D. DeRocco @ 2017-04-17 2:01 ` Khem Raj 2017-04-17 3:08 ` Bruce Ashfield 1 sibling, 0 replies; 6+ messages in thread From: Khem Raj @ 2017-04-17 2:01 UTC (permalink / raw) To: Paul D. DeRocco, yocto [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Patch failures 2017-04-16 23:43 Patch failures Paul D. DeRocco 2017-04-17 2:01 ` Khem Raj @ 2017-04-17 3:08 ` Bruce Ashfield 2017-04-17 6:18 ` Paul D. DeRocco 1 sibling, 1 reply; 6+ messages in thread From: Bruce Ashfield @ 2017-04-17 3:08 UTC (permalink / raw) To: Paul D. DeRocco, yocto 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? > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Patch failures 2017-04-17 3:08 ` Bruce Ashfield @ 2017-04-17 6:18 ` Paul D. DeRocco 2017-04-19 16:24 ` Bruce Ashfield 0 siblings, 1 reply; 6+ messages in thread From: Paul D. DeRocco @ 2017-04-17 6:18 UTC (permalink / raw) To: 'Bruce Ashfield', yocto [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Patch failures 2017-04-17 6:18 ` Paul D. DeRocco @ 2017-04-19 16:24 ` Bruce Ashfield 2017-04-19 18:02 ` Bruce Ashfield 0 siblings, 1 reply; 6+ messages in thread From: Bruce Ashfield @ 2017-04-19 16:24 UTC (permalink / raw) To: Paul D. DeRocco, yocto 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. > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Patch failures 2017-04-19 16:24 ` Bruce Ashfield @ 2017-04-19 18:02 ` Bruce Ashfield 0 siblings, 0 replies; 6+ messages in thread From: Bruce Ashfield @ 2017-04-19 18:02 UTC (permalink / raw) To: Paul D. DeRocco, yocto 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. >> > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-04-19 18:02 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-16 23:43 Patch failures Paul D. DeRocco 2017-04-17 2:01 ` Khem Raj 2017-04-17 3:08 ` Bruce Ashfield 2017-04-17 6:18 ` Paul D. DeRocco 2017-04-19 16:24 ` Bruce Ashfield 2017-04-19 18:02 ` Bruce Ashfield
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.