kernel-yocto: consolidated pull request
cover kernel-yocto: consolidated pull request
Hi all,
Here's the collected set of kernel changes that are ready for the M3 builds.
We have some kernel meta data changes:
kernel-yocto: configuration updates: x86 features linux-yocto/4.1: fix fsl-ls10xx sdhci
linux-yocto: add usb-net configs by default
Some bug fixes:
kernel-yocto: ensure that only valid BSPs are built linux-yocto/4.10: CVE & misc fixes
And the important changes are the addition of the 4.12 kernel + libc headers and the removal of the 4.1 kernel.
I also have some -stable updates queued for the active kernel versions, but they will come out once this series has made it into the tree, since I'm trying to isolate any 4.12 issues from other -stable updates.
I built and booted all the qemu targets for 4.12, and have built for core-image-sato, core-image-kernel-dev, glibc and muslc for all of the architectures. My testing didn't pick up any regressions, but I was battling some other build errors (non kernel related) during my testing, so I can never be 100% sure.
I've sent patches to poky to remove/bump any references to the 4.1 kernel .. if I've missed any, I'm sure people will shout.
Cheers,
Bruce
The following changes since commit 04dc76713b57f28457742dd863caa663591d4866:
devtool/copy_buildsystem: adds meta-skeleton layer in the eSDK installation. (2017-08-19 22:15:39 +0100)
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 (9):
kernel-yocto: configuration updates: x86 features linux-yocto/4.1: fix fsl-ls10xx sdhci
linux-yocto: add usb-net configs by default
linux-yocto: introduce 4.12 recipes
linux-yocto: remove 4.1 recipes
libc-headers: update to 4.12
qemu: bump default version to 4.12
kernel-yocto: ensure that only valid BSPs are built linux-yocto/4.10: CVE & misc fixes
meta/classes/kernel-yocto.bbclass | 3 +++
meta/conf/distro/include/tcmode-default.inc | 2 +-
meta/conf/machine/include/x86-base.inc | 2 +-
meta/conf/machine/qemuarm.conf | 2 +-
.../kern-tools/kern-tools-native_git.bb | 2 +-
...-headers_4.10.bb => linux-libc-headers_4.12.bb} | 4 ++--
meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb | 4 ++--
...inux-yocto-rt_4.1.bb => linux-yocto-rt_4.12.bb} | 12 +++++-----
meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-rt_4.9.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_4.10.bb | 4 ++--
...-yocto-tiny_4.1.bb => linux-yocto-tiny_4.12.bb} | 12 +++++-----
meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_4.9.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_4.10.bb | 18 +++++++--------
.../{linux-yocto_4.1.bb => linux-yocto_4.12.bb} | 26 ++++++++++++----------
meta/recipes-kernel/linux/linux-yocto_4.4.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_4.9.bb | 2 +-
18 files changed, 56 insertions(+), 47 deletions(-)
rename meta/recipes-kernel/linux-libc-headers/{linux-libc-headers_4.10.bb => linux-libc-headers_4.12.bb} (71%)
rename meta/recipes-kernel/linux/{linux-yocto-rt_4.1.bb => linux-yocto-rt_4.12.bb} (76%)
rename meta/recipes-kernel/linux/{linux-yocto-tiny_4.1.bb => linux-yocto-tiny_4.12.bb} (52%)
rename meta/recipes-kernel/linux/{linux-yocto_4.1.bb => linux-yocto_4.12.bb} (56%)Signature · 1 line
2.5.0
PATCH 1/9 kernel-yocto: configuration updates: x86 features
Integrating the following kernel configuration changes:
f7fbd4185e5 features/qat: additional configurations, CONFIG_CRYPTO_RSA and CONFIG_CRYPTO_DH 50c62581d283 features/netfilter: additional configurations
d67e4ed89556 features/x2apic: add X2APIC feature
7889b28c5300 features/vfio: add VFIO feature
dc4ec998757e features/numa: Add NUMA feature
c88c18de4ca8 features/mtd: add MTD feature
9035571d32ee features/iommu: add IOMMU feature
6f3b16136f55 features/intel-txt: add intel-txt feature
4936a5f508f0 common-pc-wifi: Enable SDIO for BroadCom BRCMFMAC
--- meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_4.9.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-tiny_4.10.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-tiny_4.9.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.10.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.9.bb | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-)
meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb +1 -1
@@ -12,7 +12,7 @@ python () { } SRCREV_machine ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_meta ?= "e92bd55409a6ded89642f5ac22391487364ac798" +SRCREV_meta ?= "ba079c7ed914d6502351da16c6b4ccf1e285ebdc" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.10.git;branch=${KBRANCH};name=machine \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.10;destsuffix=${KMETA}"
meta/recipes-kernel/linux/linux-yocto-rt_4.9.bb +1 -1
@@ -12,7 +12,7 @@ python () { } SRCREV_machine ?= "1fb4e1d1e3f727fc20963fc631a259665bd4665b" -SRCREV_meta ?= "0db0b4a408f05cfed359983d7ff63b1a6e29be2c" +SRCREV_meta ?= "5ea1dcf54080af3b06678f2eab8beb8194a3b1ae" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.9.git;branch=${KBRANCH};name=machine \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.9;destsuffix=${KMETA}"
meta/recipes-kernel/linux/linux-yocto-tiny_4.10.bb +1 -1
@@ -10,7 +10,7 @@ KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" SRCREV_machine ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_meta ?= "e92bd55409a6ded89642f5ac22391487364ac798" +SRCREV_meta ?= "ba079c7ed914d6502351da16c6b4ccf1e285ebdc" PV = "${LINUX_VERSION}+git${SRCPV}"
meta/recipes-kernel/linux/linux-yocto-tiny_4.9.bb +1 -1
@@ -10,7 +10,7 @@ KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" SRCREV_machine ?= "24572abb2cad341dd79e6aafcb9cdd1a7f8a0c1e" -SRCREV_meta ?= "0db0b4a408f05cfed359983d7ff63b1a6e29be2c" +SRCREV_meta ?= "5ea1dcf54080af3b06678f2eab8beb8194a3b1ae" PV = "${LINUX_VERSION}+git${SRCPV}"
meta/recipes-kernel/linux/linux-yocto_4.10.bb +1 -1
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" SRCREV_machine_qemux86-64 ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" SRCREV_machine_qemumips64 ?= "b442c964432938cbe10c4cc578260353045af980" SRCREV_machine ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_meta ?= "e92bd55409a6ded89642f5ac22391487364ac798" +SRCREV_meta ?= "ba079c7ed914d6502351da16c6b4ccf1e285ebdc" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.10.git;name=machine;branch=${KBRANCH}; \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.10;destsuffix=${KMETA}"
meta/recipes-kernel/linux/linux-yocto_4.9.bb +1 -1
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= "24572abb2cad341dd79e6aafcb9cdd1a7f8a0c1e" SRCREV_machine_qemux86-64 ?= "24572abb2cad341dd79e6aafcb9cdd1a7f8a0c1e" SRCREV_machine_qemumips64 ?= "7c9ce18e05e1d84df17e677b26133671ec0430f5" SRCREV_machine ?= "24572abb2cad341dd79e6aafcb9cdd1a7f8a0c1e" -SRCREV_meta ?= "0db0b4a408f05cfed359983d7ff63b1a6e29be2c" +SRCREV_meta ?= "5ea1dcf54080af3b06678f2eab8beb8194a3b1ae" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.9.git;name=machine;branch=${KBRANCH}; \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.9;destsuffix=${KMETA}"
Signature · 1 line
2.5.0
PATCH 2/9 linux-yocto/4.1: fix fsl-ls10xx sdhci
In reply to Bruce Ashfieldmmc: sdhci: fix two compile errors
| CC drivers/mmc/host/sdhci.o
| drivers/mmc/host/sdhci.c: In function 'sdhci_execute_tuning':
| drivers/mmc/host/sdhci.c:1990:4: error: implicit
| declaration of function 'sdhci_do_reset'
| [-Werror=implicit-function-declaration]
| sdhci_do_reset(host, SDHCI_RESET_CMD);
| ^
| drivers/mmc/host/sdhci.c:2006:7: error: 'struct
| mmc_command' has no member named 'busy_timeout'
| cmd.busy_timeout = 50;
| ^
In function sdhci_execute_tuning, replace sdhci_do_reset with sdhci_reset, replace busy_timeout with cmd_timeout_ms.
Commit a629a90ba0 adds eMMC DDR mode support for t2080qds and modified some data structures and function name. Later commit a2080cc280 just backport upstream commit 61e53bd004 without aligning the current source tree thus cause these build errors. Fix them.
--- meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.1.bb | 16 ++++++++-------- 3 files changed, 10 insertions(+), 10 deletions(-)
meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb +1 -1
@@ -11,7 +11,7 @@ python () { raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it") } -SRCREV_machine ?= "798e2cbf3dec954f37cb84463bc0b0a95cb54c8f" +SRCREV_machine ?= "091d8c17b1ba75344ed88a909ead563139de68b3" SRCREV_meta ?= "9f9c9a66ef3452343586adf150137967e955d71a" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \
meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb +1 -1
@@ -9,7 +9,7 @@ LINUX_VERSION ?= "4.1.42" KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" -SRCREV_machine ?= "e2bea2e96fcbbbb9b1efc3bc7505ac42e39bb5c0" +SRCREV_machine ?= "f905fdd5da150ea809f847f00f3476220606c0ff" SRCREV_meta ?= "9f9c9a66ef3452343586adf150137967e955d71a" PV = "${LINUX_VERSION}+git${SRCPV}"
meta/recipes-kernel/linux/linux-yocto_4.1.bb +8 -8
@@ -11,14 +11,14 @@ KBRANCH_qemux86 ?= "standard/base" KBRANCH_qemux86-64 ?= "standard/base" KBRANCH_qemumips64 ?= "standard/mti-malta64" -SRCREV_machine_qemuarm ?= "f100a3d840596ac0dc47416336f34d8bf7b5ffa8" -SRCREV_machine_qemuarm64 ?= "e2bea2e96fcbbbb9b1efc3bc7505ac42e39bb5c0" -SRCREV_machine_qemumips ?= "4005321dfa890df693c12e902e48fd0dde88fee7" -SRCREV_machine_qemuppc ?= "1e29490accfb0547e3a854ac6ec9a6754cd47204" -SRCREV_machine_qemux86 ?= "e2bea2e96fcbbbb9b1efc3bc7505ac42e39bb5c0" -SRCREV_machine_qemux86-64 ?= "e2bea2e96fcbbbb9b1efc3bc7505ac42e39bb5c0" -SRCREV_machine_qemumips64 ?= "87c0f4d5bec646565e493d39bf57c3500151ed68" -SRCREV_machine ?= "e2bea2e96fcbbbb9b1efc3bc7505ac42e39bb5c0" +SRCREV_machine_qemuarm ?= "b7334672abf08f9dc9e277969e9266785580fa80" +SRCREV_machine_qemuarm64 ?= "f905fdd5da150ea809f847f00f3476220606c0ff" +SRCREV_machine_qemumips ?= "664fb3764bc804bfc9fd8ff582b374299e1fc016" +SRCREV_machine_qemuppc ?= "7392e713c9eb1c67e9e6f8f2d14cae44467c1fbe" +SRCREV_machine_qemux86 ?= "f905fdd5da150ea809f847f00f3476220606c0ff" +SRCREV_machine_qemux86-64 ?= "f905fdd5da150ea809f847f00f3476220606c0ff" +SRCREV_machine_qemumips64 ?= "85e973a2366e2a42d5082f5cd57852f8086502f4" +SRCREV_machine ?= "f905fdd5da150ea809f847f00f3476220606c0ff" SRCREV_meta ?= "9f9c9a66ef3452343586adf150137967e955d71a" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH}; \
Signature · 1 line
2.5.0
PATCH 3/9 linux-yocto: add usb-net configs by default
In reply to Bruce AshfieldAs requested by QA to enable testing of linux-yocto images out of the box, we enable usb-net drivers for the various platforms in all kernel versions.
--- meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-rt_4.9.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-tiny_4.10.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto-tiny_4.9.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.1.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.10.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.4.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.9.bb | 2 +- 12 files changed, 12 insertions(+), 12 deletions(-)
meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb +1 -1
@@ -12,7 +12,7 @@ python () { } SRCREV_machine ?= "091d8c17b1ba75344ed88a909ead563139de68b3" -SRCREV_meta ?= "9f9c9a66ef3452343586adf150137967e955d71a" +SRCREV_meta ?= "660468df599bbd79a287a8a703d9ca066fd6a074" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb +1 -1
@@ -12,7 +12,7 @@ python () { } SRCREV_machine ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_meta ?= "ba079c7ed914d6502351da16c6b4ccf1e285ebdc" +SRCREV_meta ?= "d6ece632214e3bee843e485487e5f0d6939630a8" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.10.git;branch=${KBRANCH};name=machine \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.10;destsuffix=${KMETA}"
meta/recipes-kernel/linux/linux-yocto-rt_4.4.bb +1 -1
@@ -12,7 +12,7 @@ python () { } SRCREV_machine ?= "be70c37e4c370a8fe2ffef9e3300a266085588c4" -SRCREV_meta ?= "fbb3579c4011befe15368fea05f600d37b3444ba" +SRCREV_meta ?= "10332510892eaf50de4c92e8269fff03efc69240" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.4.git;branch=${KBRANCH};name=machine \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
meta/recipes-kernel/linux/linux-yocto-rt_4.9.bb +1 -1
@@ -12,7 +12,7 @@ python () { } SRCREV_machine ?= "1fb4e1d1e3f727fc20963fc631a259665bd4665b" -SRCREV_meta ?= "5ea1dcf54080af3b06678f2eab8beb8194a3b1ae" +SRCREV_meta ?= "e8095d45e15f02ffc953312bb41a57554b25a439" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.9.git;branch=${KBRANCH};name=machine \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.9;destsuffix=${KMETA}"
meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb +1 -1
@@ -10,7 +10,7 @@ KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" SRCREV_machine ?= "f905fdd5da150ea809f847f00f3476220606c0ff" -SRCREV_meta ?= "9f9c9a66ef3452343586adf150137967e955d71a" +SRCREV_meta ?= "660468df599bbd79a287a8a703d9ca066fd6a074" PV = "${LINUX_VERSION}+git${SRCPV}"
meta/recipes-kernel/linux/linux-yocto-tiny_4.10.bb +1 -1
@@ -10,7 +10,7 @@ KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" SRCREV_machine ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_meta ?= "ba079c7ed914d6502351da16c6b4ccf1e285ebdc" +SRCREV_meta ?= "d6ece632214e3bee843e485487e5f0d6939630a8" PV = "${LINUX_VERSION}+git${SRCPV}"
meta/recipes-kernel/linux/linux-yocto-tiny_4.4.bb +1 -1
@@ -10,7 +10,7 @@ KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" SRCREV_machine ?= "2854678e4ccbb4bbd1bb4c243ac3e2571ef9834a" -SRCREV_meta ?= "fbb3579c4011befe15368fea05f600d37b3444ba" +SRCREV_meta ?= "10332510892eaf50de4c92e8269fff03efc69240" PV = "${LINUX_VERSION}+git${SRCPV}"
meta/recipes-kernel/linux/linux-yocto-tiny_4.9.bb +1 -1
@@ -10,7 +10,7 @@ KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" SRCREV_machine ?= "24572abb2cad341dd79e6aafcb9cdd1a7f8a0c1e" -SRCREV_meta ?= "5ea1dcf54080af3b06678f2eab8beb8194a3b1ae" +SRCREV_meta ?= "e8095d45e15f02ffc953312bb41a57554b25a439" PV = "${LINUX_VERSION}+git${SRCPV}"
meta/recipes-kernel/linux/linux-yocto_4.1.bb +1 -1
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= "f905fdd5da150ea809f847f00f3476220606c0ff" SRCREV_machine_qemux86-64 ?= "f905fdd5da150ea809f847f00f3476220606c0ff" SRCREV_machine_qemumips64 ?= "85e973a2366e2a42d5082f5cd57852f8086502f4" SRCREV_machine ?= "f905fdd5da150ea809f847f00f3476220606c0ff" -SRCREV_meta ?= "9f9c9a66ef3452343586adf150137967e955d71a" +SRCREV_meta ?= "660468df599bbd79a287a8a703d9ca066fd6a074" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH}; \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
meta/recipes-kernel/linux/linux-yocto_4.10.bb +1 -1
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" SRCREV_machine_qemux86-64 ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" SRCREV_machine_qemumips64 ?= "b442c964432938cbe10c4cc578260353045af980" SRCREV_machine ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_meta ?= "ba079c7ed914d6502351da16c6b4ccf1e285ebdc" +SRCREV_meta ?= "d6ece632214e3bee843e485487e5f0d6939630a8" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.10.git;name=machine;branch=${KBRANCH}; \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.10;destsuffix=${KMETA}"
meta/recipes-kernel/linux/linux-yocto_4.4.bb +1 -1
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= "2854678e4ccbb4bbd1bb4c243ac3e2571ef9834a" SRCREV_machine_qemux86-64 ?= "2854678e4ccbb4bbd1bb4c243ac3e2571ef9834a" SRCREV_machine_qemumips64 ?= "45dd25b50163846c3346b93a21e967c68ab92b26" SRCREV_machine ?= "2854678e4ccbb4bbd1bb4c243ac3e2571ef9834a" -SRCREV_meta ?= "fbb3579c4011befe15368fea05f600d37b3444ba" +SRCREV_meta ?= "10332510892eaf50de4c92e8269fff03efc69240" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=${KBRANCH}; \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
meta/recipes-kernel/linux/linux-yocto_4.9.bb +1 -1
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= "24572abb2cad341dd79e6aafcb9cdd1a7f8a0c1e" SRCREV_machine_qemux86-64 ?= "24572abb2cad341dd79e6aafcb9cdd1a7f8a0c1e" SRCREV_machine_qemumips64 ?= "7c9ce18e05e1d84df17e677b26133671ec0430f5" SRCREV_machine ?= "24572abb2cad341dd79e6aafcb9cdd1a7f8a0c1e" -SRCREV_meta ?= "5ea1dcf54080af3b06678f2eab8beb8194a3b1ae" +SRCREV_meta ?= "e8095d45e15f02ffc953312bb41a57554b25a439" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.9.git;name=machine;branch=${KBRANCH}; \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.9;destsuffix=${KMETA}"
Signature · 1 line
2.5.0
PATCH 4/9 linux-yocto: introduce 4.12 recipes
In reply to Bruce AshfieldThe 4.12 kernel will be the default/reference for the fall 2017 release.
These recipes represent the introduction of 4.12.7 + related kernel meta data. Existing functionality has been validated against this new kernel version, and older versions will be removed in separate commits.
--- meta/recipes-kernel/linux/linux-yocto-rt_4.12.bb | 38 +++++++++++++++++++ meta/recipes-kernel/linux/linux-yocto-tiny_4.12.bb | 25 ++++++++++++ meta/recipes-kernel/linux/linux-yocto_4.12.bb | 44 ++++++++++++++++++++++ 3 files changed, 107 insertions(+) create mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_4.12.bb create mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_4.12.bb create mode 100644 meta/recipes-kernel/linux/linux-yocto_4.12.bb
meta/recipes-kernel/linux/linux-yocto-rt_4.12.bb new file +38 -0
@@ -0,0 +1,38 @@ +KBRANCH ?= "standard/preempt-rt/base" + +require recipes-kernel/linux/linux-yocto.inc + +# Skip processing of this recipe if it is not explicitly specified as the +# PREFERRED_PROVIDER for virtual/kernel. This avoids errors when trying +# to build multiple virtual/kernel providers, e.g. as dependency of +# core-image-rt-sdk, core-image-rt. +python () { + if d.getVar("PREFERRED_PROVIDER_virtual/kernel") != "linux-yocto-rt": + raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it") +} + +SRCREV_machine ?= "918fc2fbdf48e86748a3600a5e79d1abcd71b92e" +SRCREV_meta ?= "b8983853109591bee91b268dccc075acfc7e45a2" + +SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.12.git;branch=${KBRANCH};name=machine \ + git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}" + +LINUX_VERSION ?= "4.12.7" + +PV = "${LINUX_VERSION}+git${SRCPV}" + +KMETA = "kernel-meta" +KCONF_BSP_AUDIT_LEVEL = "2" + +LINUX_KERNEL_TYPE = "preempt-rt" + +COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)" + +KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb" + +# Functionality flags +KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc" +KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" +KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc" +KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" +KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
meta/recipes-kernel/linux/linux-yocto-tiny_4.12.bb new file +25 -0
@@ -0,0 +1,25 @@ +KBRANCH ?= "standard/tiny/common-pc" +LINUX_KERNEL_TYPE = "tiny" +KCONFIG_MODE = "--allnoconfig" + +require recipes-kernel/linux/linux-yocto.inc + +LINUX_VERSION ?= "4.12.7" + +KMETA = "kernel-meta" +KCONF_BSP_AUDIT_LEVEL = "2" + +SRCREV_machine ?= "918fc2fbdf48e86748a3600a5e79d1abcd71b92e" +SRCREV_meta ?= "b8983853109591bee91b268dccc075acfc7e45a2" + +PV = "${LINUX_VERSION}+git${SRCPV}" + +SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.12.git;branch=${KBRANCH};name=machine \ + git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.12;destsuffix=${KMETA}" + +COMPATIBLE_MACHINE = "(qemux86$)" + +# Functionality flags +KERNEL_FEATURES = "" + +KERNEL_DEVICETREE_qemuarm = "versatile-pb.dtb"
meta/recipes-kernel/linux/linux-yocto_4.12.bb new file +44 -0
44 lines not on this page · raw message
Signature · 1 line
2.5.0
PATCH 5/9 linux-yocto: remove 4.1 recipes
In reply to Bruce AshfieldWe have 4.4 and 4.9 as LTS kernels, the 4.1 variants are no longer needed and are dropped.
--- meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb | 36 ------------------- meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb | 23 ------------- meta/recipes-kernel/linux/linux-yocto_4.1.bb | 42 ----------------------- 3 files changed, 101 deletions(-) delete mode 100644 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb delete mode 100644 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb delete mode 100644 meta/recipes-kernel/linux/linux-yocto_4.1.bb
meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb deleted +0 -36
@@ -1,36 +0,0 @@ -KBRANCH ?= "standard/preempt-rt/base" - -require recipes-kernel/linux/linux-yocto.inc - -# Skip processing of this recipe if it is not explicitly specified as the -# PREFERRED_PROVIDER for virtual/kernel. This avoids errors when trying -# to build multiple virtual/kernel providers, e.g. as dependency of -# core-image-rt-sdk, core-image-rt. -python () { - if d.getVar("PREFERRED_PROVIDER_virtual/kernel") != "linux-yocto-rt": - raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it") -} - -SRCREV_machine ?= "091d8c17b1ba75344ed88a909ead563139de68b3" -SRCREV_meta ?= "660468df599bbd79a287a8a703d9ca066fd6a074" - -SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \ - git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}" - -LINUX_VERSION ?= "4.1.42" - -PV = "${LINUX_VERSION}+git${SRCPV}" - -KMETA = "kernel-meta" -KCONF_BSP_AUDIT_LEVEL = "2" - -LINUX_KERNEL_TYPE = "preempt-rt" - -COMPATIBLE_MACHINE = "(qemux86|qemux86-64|qemuarm|qemuppc|qemumips)" - -# Functionality flags -KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc" -KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}" -KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc" -KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc" -KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb deleted +0 -23
@@ -1,23 +0,0 @@ -KBRANCH ?= "standard/tiny/common-pc" -LINUX_KERNEL_TYPE = "tiny" -KCONFIG_MODE = "--allnoconfig" - -require recipes-kernel/linux/linux-yocto.inc - -LINUX_VERSION ?= "4.1.42" - -KMETA = "kernel-meta" -KCONF_BSP_AUDIT_LEVEL = "2" - -SRCREV_machine ?= "f905fdd5da150ea809f847f00f3476220606c0ff" -SRCREV_meta ?= "660468df599bbd79a287a8a703d9ca066fd6a074" - -PV = "${LINUX_VERSION}+git${SRCPV}" - -SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \ - git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}" - -COMPATIBLE_MACHINE = "(qemux86$)" - -# Functionality flags -KERNEL_FEATURES = ""
meta/recipes-kernel/linux/linux-yocto_4.1.bb deleted +0 -42
42 lines not on this page · raw message
Signature · 1 line
2.5.0
PATCH 6/9 libc-headers: update to 4.12
In reply to Bruce AshfieldThe fall 2017 kernel will have 4.12 as the reference kernel, so we update the libc-headers to match.
Build tested against glibc and muslc systems.
---
meta/conf/distro/include/tcmode-default.inc | 2 +-
.../{linux-libc-headers_4.10.bb => linux-libc-headers_4.12.bb} | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-kernel/linux-libc-headers/{linux-libc-headers_4.10.bb => linux-libc-headers_4.12.bb} (71%)meta/conf/distro/include/tcmode-default.inc +1 -1
@@ -27,7 +27,7 @@ SDKGCCVERSION ?= "${GCCVERSION}" BINUVERSION ?= "2.29%" GDBVERSION ?= "8.0%" GLIBCVERSION ?= "2.26%" -LINUXLIBCVERSION ?= "4.10%" +LINUXLIBCVERSION ?= "4.12%" PREFERRED_VERSION_gcc ?= "${GCCVERSION}" PREFERRED_VERSION_gcc-cross-${TARGET_ARCH} ?= "${GCCVERSION}"
meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.12.bb renamed from meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.10.bb +2 -2
@@ -7,5 +7,5 @@ SRC_URI_append_libc-musl = "\ file://0001-libc-compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch \ " -SRC_URI[md5sum] = "b5e7f6b9b2fe1b6cc7bc56a3a0bfc090" -SRC_URI[sha256sum] = "3c95d9f049bd085e5c346d2c77f063b8425f191460fcd3ae9fe7e94e0477dc4b" +SRC_URI[md5sum] = "fc454157e2d024d401a60905d6481c6b" +SRC_URI[sha256sum] = "a45c3becd4d08ce411c14628a949d08e2433d8cdeca92036c7013980e93858ab"
Signature · 1 line
2.5.0
PATCH 7/9 qemu: bump default version to 4.12
In reply to Bruce AshfieldNot all the qemu machines carry default kernel specifications. While we could drop these references, we'll bump them to 4.12 to pick up the latest and remove them in future commits.
--- meta/conf/machine/include/x86-base.inc | 2 +- meta/conf/machine/qemuarm.conf | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
meta/conf/machine/include/x86-base.inc +1 -1
@@ -21,7 +21,7 @@ SERIAL_CONSOLE ?= "115200 ttyS0" # kernel-related variables # PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto" -PREFERRED_VERSION_linux-yocto ??= "4.10%" +PREFERRED_VERSION_linux-yocto ??= "4.12%" # # XSERVER subcomponents, used to build the XSERVER variable
meta/conf/machine/qemuarm.conf +1 -1
@@ -16,5 +16,5 @@ QB_MACHINE = "-machine versatilepb" QB_KERNEL_CMDLINE_APPEND = "console=ttyAMA0,115200 console=tty" # Add the 'virtio-rng-pci' device otherwise the guest may run out of entropy QB_OPT_APPEND = "-show-cursor -usb -device usb-tablet -device virtio-rng-pci" -PREFERRED_VERSION_linux-yocto ??= "4.10%" +PREFERRED_VERSION_linux-yocto ??= "4.12%" QB_DTB = "${@base_version_less_or_equal('PREFERRED_VERSION_linux-yocto', '4.7', '', 'zImage-versatile-pb.dtb', d)}"
Signature · 1 line
2.5.0
PATCH 8/9 kernel-yocto: ensure that only valid BSPs are built
In reply to Bruce AshfieldThere was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched.
This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user.
[YOCTO: #11878]
--- meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)
meta/classes/kernel-yocto.bbclass +3 -0
@@ -143,6 +143,9 @@ do_kernel_metadata() { # expand kernel features into their full path equivalents bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then + bbfatal_log "Could not locate BSP definiton for ${KMACHINE}/${LINUX_KERNEL_TYPE}." + fi meta_dir=$(kgit --meta) # run1: pull all the configuration fragments, no matter where they come from
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1 -1
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b DEPENDS = "git-native" -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c" +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83" PR = "r12" PV = "0.2+git${SRCPV}"
Signature · 1 line
2.5.0
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
Quoted 35 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bruce Ashfield
Sent: den 21 augusti 2017 04:58
To: [email protected]
Cc: [email protected]
Subject: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are builtThere was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched.
This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user.
[YOCTO: #11878]
Signed-off-by Bruce Ashfield <[email protected]>--- meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/kernel-yocto.bbclass +0
-0
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 146
Quoted 4 lines
meta/classes/kernel-yocto.bbclass +1
-0@@ -143,6 +143,9 @@ do_kernel_metadata() { # expand kernel features into their full path equivalents bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
Use $bsp_definition instead of ${bsp_definition} since it is a shell variable and not a bitbake variable.
Actually, after looking at the code in that bbclass, I see this used for a number of shell variables all over the place. This is actually bad, and you should rewrite the code to not use ${variable} for shell variables. The reason this is bad is because these variables unnecessarily end up in the sstate hash for these functions, and if someone actually happens to define a bitbake variable with the same name as one of those shell variables, the result will not be what is expected...
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 147
Quoted 1 line
meta/classes/kernel-yocto.bbclass +1
-0+ bbfatal_log "Could not locate BSP definiton for ${KMACHINE}/${LINUX_KERNEL_TYPE}."
Change "definiton" to "definition".
Quoted 18 lines
meta/classes/kernel-yocto.bbclass +1
-0+ fi meta_dir=$(kgit --meta) # run1: pull all the configuration fragments, no matter where they come frommeta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-2@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b DEPENDS = "git-native" -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c" +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83" PR = "r12" PV = "0.2+git${SRCPV}" --
Quoted 1 line
2.5.0
//Peter
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
Quoted 37 lines · Peter Kjellerstedt
Quoted 24 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bruce Ashfield
Sent: den 21 augusti 2017 04:58
To: [email protected]
Cc: [email protected]
Subject: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are builtThere was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched.
This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user.
[YOCTO: #11878]
Review
Quoted 7 lines
Signed-off-by Bruce Ashfield <[email protected]>--- meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)(quoted diff) +0
-0b/meta/classes/kernel-yocto.bbclass
Quoted 5 lines
index
1ca0756c4959..3c6df92131bc100644meta/classes/kernel-yocto.bbclass +0
-0@@ -143,6 +143,9 @@ do_kernel_metadata() {
Quoted 8 lines
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 145
Quoted 2 lines
meta/classes/kernel-yocto.bbclass +0
-0# expand kernel features into their full path equivalents bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}-DKTYPE=${LINUX_KERNEL_TYPE})
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 146
Quoted 1 line
meta/classes/kernel-yocto.bbclass +1
-0+ if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; thenUse $bsp_definition instead of ${bsp_definition} since it is a shell variable and not a bitbake variable.
I always use ${...}, so I'm going to stay consistent with what is already in the file.
Quoted 10 lines
Actually, after looking at the code in that bbclass, I see this used for a number of shell variables all over the place. This is actually bad, and you should rewrite the code to not use ${variable} for shell variables. The reason this is bad is because these variables unnecessarily end up in the sstate hash for these functions, and if someone actually happens to define a bitbake variable with the same name as one of those shell variables, the result will not be what is expected...
Not something high on my priority list. It's been that way since the beginning.
Cheers,
Bruce
Quoted 37 lines
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 147
Quoted 2 lines
meta/classes/kernel-yocto.bbclass +1
-0+ bbfatal_log "Could not locate BSP definiton for${KMACHINE}/${LINUX_KERNEL_TYPE}."
Change "definiton" to "definition".
meta/classes/kernel-yocto.bbclass do_kernel_metadata() {
Quoted 4 lines
meta/classes/kernel-yocto.bbclass +1
-0+ fi meta_dir=$(kgit --meta) # run1: pull all the configuration fragments, no matter where theycome from
Review
Quoted 1 line
(quoted diff) +0
-0b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb LIC_FILES_CHKSUM = "file://git/tools/kgit;
Quoted 4 lines
index
2217a31076a2..4a78b897d34f100644meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0
-0@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b
Quoted 10 lines
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-2DEPENDS = "git-native" -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c" +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83" PR = "r12" PV = "0.2+git${SRCPV}" --2.5.0
//Peter
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
Quoted 67 lines · Bruce Ashfield
Quoted 37 lines · Peter Kjellerstedt
meta/classes/
Quoted 31 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bruce Ashfield
Sent: den 21 augusti 2017 04:58
To: [email protected]
Cc: [email protected]
Subject: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are builtThere was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched.
This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user.
[YOCTO: #11878]
Signed-off-by Bruce Ashfield <[email protected]>--- meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/ renamed from meta/classes/kernel-yocto.bbclass +0
-0kernel-yocto.bbclass
Quoted 5 lines
index
1ca0756c4959..3c6df92131bc100644meta/classes/kernel-yocto.bbclass +0
-0@@ -143,6 +143,9 @@ do_kernel_metadata() {Quoted 8 lines
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 145
Quoted 2 lines
meta/classes/kernel-yocto.bbclass +0
-0# expand kernel features into their full path equivalents bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}-DKTYPE=${LINUX_KERNEL_TYPE})
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 146
Quoted 1 line
meta/classes/kernel-yocto.bbclass +1
-0+ if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; thenUse $bsp_definition instead of ${bsp_definition} since it is a shell variable and not a bitbake variable.
I always use ${...}, so I'm going to stay consistent with what is already in
the file.Quoted 10 lines
Actually, after looking at the code in that bbclass, I see this used for a number of shell variables all over the place. This is actually bad, and you should rewrite the code to not use ${variable} for shell variables. The reason this is bad is because these variables unnecessarily end up in the sstate hash for these functions, and if someone actually happens to define a bitbake variable with the same name as one of those shell variables, the result will not be what is expected...
Quoted 3 lines
Not something high on my priority list. It's been that way since the beginning.
.. but I will loop back and take care of the issues before M4 closes. Just a bit busy
pushing out the new kernels and a slew of bug fixes.
This patch can be ignored (if needed) until I get back around to that.
Cheers,
Bruce
Quoted 50 lines
Cheers,
Bruce
Quoted 31 lines
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 147
Quoted 2 lines
meta/classes/kernel-yocto.bbclass +1
-0+ bbfatal_log "Could not locate BSP definiton for${KMACHINE}/${LINUX_KERNEL_TYPE}."
Change "definiton" to "definition".
meta/classes/kernel-yocto.bbclass do_kernel_metadata() {
Quoted 4 lines
meta/classes/kernel-yocto.bbclass +1
-0+ fi meta_dir=$(kgit --meta) # run1: pull all the configuration fragments, no matter wherethey come from
Review
Quoted 1 line
(quoted diff) +0
-0b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb LIC_FILES_CHKSUM = "file://git/tools/kgit;beginli
Quoted 4 lines
index
2217a31076a2..4a78b897d34f100644meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0
-0@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b
Quoted 10 lines
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-2DEPENDS = "git-native" -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c" +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83" PR = "r12" PV = "0.2+git${SRCPV}" --2.5.0
//Peter
Quoted 6 lines
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
Just in case you missed it (as you didn’t comment on my comment about it), there was a typo in the log message as well.
//Peter
From: Bruce Ashfield [mailto:[email protected]]
Sent: den 21 augusti 2017 17:14
To: Peter Kjellerstedt <[email protected]>
Cc: [email protected]; [email protected]
Subject: Re: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
On Mon, Aug 21, 2017 at 11:03 AM, Bruce Ashfield <[email protected]<mailto:[email protected]>> wrote:
Quoted 35 lines · On Mon, Aug 21, 2017 at 11:00 AM, Peter Kjellerstedt…
-----Original Message-----
From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Bruce Ashfield
Sent: den 21 augusti 2017 04:58
To: [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
Subject: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid
BSPs are builtThere was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched.
This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user.
[YOCTO: #11878]
--- meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb<http://kern-tools-native_git.bb> | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/kernel-yocto.bb<http://kernel-yocto.bb>class +0
-0
meta/classes/kernel-yocto.bb<http://kernel-yocto.bb>class do_kernel_metadata() { · line 146
Quoted 4 lines
meta/classes/kernel-yocto.bb<http://kernel-yocto.bb>class +1
-0@@ -143,6 +143,9 @@ do_kernel_metadata() { # expand kernel features into their full path equivalents bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then
Use $bsp_definition instead of ${bsp_definition} since it is a shell variable and not a bitbake variable.
I always use ${...}, so I'm going to stay consistent with what is already in the file.
Actually, after looking at the code in that bbclass, I see this used for a number of shell variables all over the place. This is actually bad, and you should rewrite the code to not use ${variable} for shell variables. The reason this is bad is because these variables unnecessarily end up in the sstate hash for these functions, and if someone actually happens to define a bitbake variable with the same name as one of those shell variables, the result will not be what is expected...
Not something high on my priority list. It's been that way since the beginning.
.. but I will loop back and take care of the issues before M4 closes. Just a bit busy pushing out the new kernels and a slew of bug fixes.
This patch can be ignored (if needed) until I get back around to that.
Cheers,
Bruce
Cheers,
Bruce
meta/classes/kernel-yocto.bb<http://kernel-yocto.bb>class do_kernel_metadata() { · line 147
Quoted 1 line
meta/classes/kernel-yocto.bb<http://kernel-yocto.bb>class +1
-0+ bbfatal_log "Could not locate BSP definiton for ${KMACHINE}/${LINUX_KERNEL_TYPE}."
Change "definiton" to "definition".
Quoted 18 lines
meta/classes/kernel-yocto.bb<http://kernel-yocto.bb>class +1
-0+ fi meta_dir=$(kgit --meta) # run1: pull all the configuration fragments, no matter where they come frommeta/recipes-kernel/kern-tools/kern-tools-native_git.bb<http://kern-tools-native_git.bb> +1
-2@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b DEPENDS = <file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b%0b%3e%0b%3e %20DEPENDS%20=%20> "git-native" -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c" +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83" PR = "r12" PV = "0.2+git${SRCPV}" --
Quoted 1 line
2.5.0
//Peter
--
_______________________________________________
Openembedded-core mailing list [email protected]<mailto:[email protected]>
http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
Quoted 3 lines · Peter Kjellerstedt
Just in case you missed it (as you didn’t comment on my comment about it), there was a typo in the log message as well.
Yup. Noticed that, it isn't the only typo ;)
This is a resend of a patch I sent a few weeks ago, so I'm not too worried if it sits or not.
Cheers,
Bruce
Quoted 186 lines
//Peter
*From:* Bruce Ashfield [mailto:[email protected]] *Sent:* den 21 augusti 2017 17:14
*To:* Peter Kjellerstedt <[email protected]>
*Cc:* [email protected]; openembedded-core@lists. openembedded.org
*Subject:* Re: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are builtOn Mon, Aug 21, 2017 at 11:03 AM, Bruce Ashfield <[email protected]> wrote:
meta/classes/
Quoted 31 lines · Peter Kjellerstedt
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bruce Ashfield
Sent: den 21 augusti 2017 04:58
To: [email protected]
Cc: [email protected]
Subject: [OE-core] [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are builtThere was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched.
This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user.
[YOCTO: #11878]
Signed-off-by Bruce Ashfield <[email protected]>--- meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/ renamed from meta/classes/kernel-yocto.bbclass +0
-0kernel-yocto.bbclass
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 145
Quoted 7 lines
index
1ca0756c4959..3c6df92131bc100644meta/classes/kernel-yocto.bbclass +0
-0@@ -143,6 +143,9 @@ do_kernel_metadata() { # expand kernel features into their full path equivalents bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE}-DKTYPE=${LINUX_KERNEL_TYPE})
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 146
Quoted 1 line
meta/classes/kernel-yocto.bbclass +1
-0+ if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; thenUse $bsp_definition instead of ${bsp_definition} since it is a shell variable and not a bitbake variable.
I always use ${...}, so I'm going to stay consistent with what is already in
the file.
Actually, after looking at the code in that bbclass, I see this used for a number of shell variables all over the place. This is actually bad, and you should rewrite the code to not use ${variable} for shell variables. The reason this is bad is because these variables unnecessarily end up in the sstate hash for these functions, and if someone actually happens to define a bitbake variable with the same name as one of those shell variables, the result will not be what is expected...
Not something high on my priority list. It's been that way since the beginning.
.. but I will loop back and take care of the issues before M4 closes. Just a bit busy
pushing out the new kernels and a slew of bug fixes.
This patch can be ignored (if needed) until I get back around to that.
Cheers,
Bruce
Cheers,
Bruce
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 147
Quoted 1 line
meta/classes/kernel-yocto.bbclass +1
-0+ bbfatal_log "Could not locate BSP definiton for${KMACHINE}/${LINUX_KERNEL_TYPE}."
Change "definiton" to "definition".
meta/classes/kernel-yocto.bbclass do_kernel_metadata() {
Quoted 4 lines
meta/classes/kernel-yocto.bbclass +1
-0+ fi meta_dir=$(kgit --meta) # run1: pull all the configuration fragments, no matter where theycome from
Review
Quoted 1 line
(quoted diff) +0
-0b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb LIC_FILES_CHKSUM = "file://git/tools/kgit;
Quoted 4 lines
index
2217a31076a2..4a78b897d34f100644meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0
-0@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b
Quoted 10 lines
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-2DEPENDS = "git-native" -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c" +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83" PR = "r12" PV = "0.2+git${SRCPV}" --2.5.0
//Peter
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
In reply to Bruce AshfieldQuoted 25 lines · Bruce Ashfield
There was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched.
This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user.
[YOCTO: #11878]
Signed-off-by Bruce Ashfield <[email protected]>--- meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/kernel-yocto.bbclass +0
-0
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 148
Quoted 6 lines
meta/classes/kernel-yocto.bbclass +3
-0@@ -143,6 +143,9 @@ do_kernel_metadata() { # expand kernel features into their full path equivalents bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then + bbfatal_log "Could not locate BSP definiton for ${KMACHINE}/${LINUX_KERNEL_TYPE}." + fi
this breaks non linux-yocto kernels which are using the kernel infra from OE-Core
since they may not have kmeta structure and bsp_definition may be empty for them so either provide a way to override bsp_definition to something dummy or infact fall back to dummy by default with a warning or note during parse time. fatal is a bit harsh here.
Quoted 24 lines
meta/classes/kernel-yocto.bbclass +0
-0meta_dir=$(kgit --meta) # run1: pull all the configuration fragments, no matter where they come frommeta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-2@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b DEPENDS = "git-native" -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c" +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83" PR = "r12" PV = "0.2+git${SRCPV}" --2.5.0
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
Quoted 28 lines · Khem Raj
Quoted 26 lines · Bruce Ashfield
There was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched.
This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user.
[YOCTO: #11878]
Signed-off-by Bruce Ashfield <[email protected]>--- meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/kernel-yocto.bbclass +0
-0@@ -143,6 +143,9 @@ do_kernel_metadata() {
Quoted 12 lines
meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 148
Quoted 5 lines
meta/classes/kernel-yocto.bbclass +3
-0# expand kernel features into their full path equivalents bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then + bbfatal_log "Could not locate BSP definiton for ${KMACHINE}/${LINUX_KERNEL_TYPE}." + fithis breaks non linux-yocto kernels which are using the kernel infra from OE-Core
since they may not have kmeta structure andbsp_definitionmay be empty for them so either provide a way to overridebsp_definitionto something dummy or infact fall back to dummy by default with a warning or note during parse time. fatal is a bit harsh here.
Fair enough. I can make it a warning versus fatal, or only make it fatal if I detect a defconfig.
The issue is that the tools haven't found a configuration entry point and could end up building a garbage/invalid configuration. A defconfig could stand in as a 'valid entry' point, since it signifies a baseline configuration.
Also, I do have completed code to move fragment merging into a common location and avoid things like this .. once it goes through some more compatibility testing, I'll post it to the list.
Bruce
Quoted 25 lines
Quoted 25 lines
meta/classes/kernel-yocto.bbclass +0
-0meta_dir=$(kgit --meta) # run1: pull all the configuration fragments, no matter where they come frommeta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-2@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b DEPENDS = "git-native" -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c" +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83" PR = "r12" PV = "0.2+git${SRCPV}" --2.5.0
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
Quoted 54 lines · Bruce Ashfield
Quoted 40 lines · Khem Raj
Quoted 33 lines · Bruce Ashfield
There was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched.
This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user.
[YOCTO: #11878]
Signed-off-by Bruce Ashfield <[email protected]>--- meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/kernel-yocto.bbclass +2
-1@@ -143,6 +143,9 @@ do_kernel_metadata() { # expand kernel features into their full path equivalents bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then + bbfatal_log "Could not locate BSP definiton forQuoted 2 lines
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+ fiQuoted 8 lines
this breaks non linux-yocto kernels which are using the kernel infra from OE-Core
since they may not have kmeta structure andbsp_definitionmay be empty for them
so either provide a way to overridebsp_definitionto something dummy or infact
fall back to dummy by default with a warning or note during parse time. fatal is a bit harsh here.Fair enough. I can make it a warning versus fatal, or only make it fatal if I detect a defconfig.
Quoted 8 lines
The issue is that the tools haven't found a configuration entry point and could end up building a garbage/invalid configuration. A defconfig could stand in as a 'valid entry' point, since it signifies a baseline configuration.
Also, I do have completed code to move fragment merging into a common location and avoid things like this .. once it goes through some more compatibility testing, I'll post it to the list.
Irrespective this was merged today into master, can you send a followup quickly so we can unbreak meta-raspberrypi
Quoted 34 lines
Bruce
Quoted 28 lines
Quoted 28 lines
meta_dir=$(kgit --meta)
# run1: pull all the configuration fragments, no matter where
they come frommeta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0
-0@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM ="file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b
DEPENDS = "git-native"
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-2-SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c" +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83" PR = "r12" PV = "0.2+git${SRCPV}" --2.5.0
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
Quoted 61 lines · Khem Raj
Quoted 59 lines · Bruce Ashfield
Quoted 40 lines · Khem Raj
Quoted 33 lines · Bruce Ashfield
There was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched.
This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user.
[YOCTO: #11878]
Signed-off-by Bruce Ashfield <[email protected]>--- meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/kernel-yocto.bbclass +2
-1@@ -143,6 +143,9 @@ do_kernel_metadata() { # expand kernel features into their full path equivalents bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then + bbfatal_log "Could not locate BSP definiton forQuoted 2 lines
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+ fiQuoted 8 lines
this breaks non linux-yocto kernels which are using the kernel infra from OE-Core
since they may not have kmeta structure andbsp_definitionmay be empty for them
so either provide a way to overridebsp_definitionto something dummy or infact
fall back to dummy by default with a warning or note during parse time. fatal is a bit harsh here.Fair enough. I can make it a warning versus fatal, or only make it fatal if I detect a defconfig.
The issue is that the tools haven't found a configuration entry point and could end up building a garbage/invalid configuration. A defconfig could stand in as a 'valid entry' point, since it signifies a baseline configuration.
Quoted 7 lines
Quoted 3 lines
Also, I do have completed code to move fragment merging into a common location and avoid things like this .. once it goes through some more compatibility testing, I'll post it to the list.
Irrespective this was merged today into master, can you send a followup quickly so we can unbreak meta-raspberrypi
I hadn't pulled today, and yes, I'll send something by end of day, since I don't want this to stay broken!
Cheers,
Bruce
Quoted 35 lines
Quoted 35 lines
Bruce
Quoted 28 lines
Quoted 28 lines
meta_dir=$(kgit --meta)
# run1: pull all the configuration fragments, no matter where
they come frommeta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0
-0@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM ="file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b
DEPENDS = "git-native"
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-2-SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c" +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83" PR = "r12" PV = "0.2+git${SRCPV}" --2.5.0
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
Quoted 88 lines · Bruce Ashfield
Quoted 87 lines · Khem Raj
Quoted 83 lines · Bruce Ashfield
Quoted 55 lines · Khem Raj
Quoted 43 lines · Bruce Ashfield
There was a bug in the search routines responsible for locating
BSP definitions which returned a valid match if only the ktype
matched.This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm"
and be none the wiser (until it didn't boot).With this fix to the tools search routine, and improved return
code testing, we will now stop the build and report and error to
the user.[YOCTO: #11878]
Signed-off-by Bruce Ashfield <[email protected]>---
meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +-2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/kernel-yocto.bbclass +0
-0@@ -143,6 +143,9 @@ do_kernel_metadata() { # expand kernel features into their full pathequivalents
bsp_definition=$(spp ${includes} --findmeta/classes/kernel-yocto.bbclass +2
-2-DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then + bbfatal_log "Could not locate BSP definitonQuoted 3 lines
for
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+ fithis breaks non linux-yocto kernels which are using the kernel infra
from OE-Core
since they may not have kmeta structure andbsp_definitionmayQuoted 8 lines
be empty
for them
so either provide a way to overridebsp_definitionto something dummy or
infact
fall back to dummy by default with a warning or note during parse
time. fatal is a bit harsh here.Fair enough. I can make it a warning versus fatal, or only make it
fatal if I detect a defconfig.The issue is that the tools haven't found a configuration entry point
and could end up building a garbage/invalid configuration. A defconfig
could stand in as a 'valid entry' point, since it signifies a baseline
configuration.Also, I do have completed code to move fragment merging into a common
location and avoid things like this .. once it goes through some more
compatibility testing, I'll post it to the list.
Quoted 6 lines
Quoted 3 lines
Irrespective this was merged today into master, can you send a followup
quickly so we can unbreak meta-raspberrypiI hadn't pulled today, and yes, I'll send something by end of day, since
I don't want this to stay broken!
Thanks, I merged this as the discussion was happening not realising there was this issue.
I did at least hopefully get all the other 4.12 issues addressed, thanks for the help there.
Cheers,
Richard
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
Quoted 96 lines · Richard Purdie
Quoted 88 lines · Bruce Ashfield
Quoted 87 lines · Khem Raj
Quoted 83 lines · Bruce Ashfield
Quoted 55 lines · Khem Raj
Quoted 43 lines · Bruce Ashfield
There was a bug in the search routines responsible for locating
BSP definitions which returned a valid match if only the ktype
matched.This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm"
and be none the wiser (until it didn't boot).With this fix to the tools search routine, and improved return
code testing, we will now stop the build and report and error to
the user.[YOCTO: #11878]
Signed-off-by Bruce Ashfield <[email protected]>---
meta/classes/kernel-yocto.bbclass |
3 +++
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |
2 +-2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/kernel-yocto.bbclass +0
-0@@ -143,6 +143,9 @@ do_kernel_metadata() { # expand kernel features into their full pathequivalents
bsp_definition=$(spp ${includes} --findmeta/classes/kernel-yocto.bbclass +2
-2-DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then + bbfatal_log "Could not locate BSP definitonQuoted 3 lines
for
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+ fithis breaks non linux-yocto kernels which are using the kernel infra
from OE-Core
since they may not have kmeta structure andbsp_definitionmayQuoted 8 lines
be empty
for them
so either provide a way to overridebsp_definitionto something dummy or
infact
fall back to dummy by default with a warning or note during parse
time. fatal is a bit harsh here.Fair enough. I can make it a warning versus fatal, or only make it
fatal if I detect a defconfig.The issue is that the tools haven't found a configuration entry point
and could end up building a garbage/invalid configuration. A defconfig
could stand in as a 'valid entry' point, since it signifies a baseline
configuration.Also, I do have completed code to move fragment merging into a common
location and avoid things like this .. once it goes through some more
compatibility testing, I'll post it to the list.Quoted 6 lines
Quoted 3 lines
Irrespective this was merged today into master, can you send a followup
quickly so we can unbreak meta-raspberrypiI hadn't pulled today, and yes, I'll send something by end of day, since
I don't want this to stay broken!
Quoted 5 lines
Thanks, I merged this as the discussion was happening not realising there was this issue.
I did at least hopefully get all the other 4.12 issues addressed, thanks for the help there.
Sounds good. This is an easy thing for me to tweak, having the original series go in as-is was the easiest way to keep things straight. My patch will be out shortly.
Bruce
Quoted 5 lines
Cheers,
Richard
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
In reply to Richard PurdieQuoted 96 lines · Richard Purdie
Quoted 88 lines · Bruce Ashfield
Quoted 87 lines · Khem Raj
Quoted 83 lines · Bruce Ashfield
Quoted 55 lines · Khem Raj
Quoted 43 lines · Bruce Ashfield
There was a bug in the search routines responsible for locating
BSP definitions which returned a valid match if only the ktype
matched.This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm"
and be none the wiser (until it didn't boot).With this fix to the tools search routine, and improved return
code testing, we will now stop the build and report and error to
the user.[YOCTO: #11878]
Signed-off-by Bruce Ashfield <[email protected]>---
meta/classes/kernel-yocto.bbclass |
3 +++
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |
2 +-2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/kernel-yocto.bbclass +0
-0@@ -143,6 +143,9 @@ do_kernel_metadata() { # expand kernel features into their full pathequivalents
bsp_definition=$(spp ${includes} --findmeta/classes/kernel-yocto.bbclass +2
-2-DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then + bbfatal_log "Could not locate BSP definitonQuoted 3 lines
for
${KMACHINE}/${LINUX_KERNEL_TYPE}."
+ fithis breaks non linux-yocto kernels which are using the kernel infra
from OE-Core
since they may not have kmeta structure andbsp_definitionmayQuoted 8 lines
be empty
for them
so either provide a way to overridebsp_definitionto something dummy or
infact
fall back to dummy by default with a warning or note during parse
time. fatal is a bit harsh here.Fair enough. I can make it a warning versus fatal, or only make it
fatal if I detect a defconfig.The issue is that the tools haven't found a configuration entry point
and could end up building a garbage/invalid configuration. A defconfig
could stand in as a 'valid entry' point, since it signifies a baseline
configuration.Also, I do have completed code to move fragment merging into a common
location and avoid things like this .. once it goes through some more
compatibility testing, I'll post it to the list.Quoted 6 lines
Quoted 3 lines
Irrespective this was merged today into master, can you send a followup
quickly so we can unbreak meta-raspberrypiI hadn't pulled today, and yes, I'll send something by end of day, since
I don't want this to stay broken!
Quoted 5 lines
Thanks, I merged this as the discussion was happening not realising there was this issue.
I did at least hopefully get all the other 4.12 issues addressed, thanks for the help there.
No worries, its a simple thing to fix I believe.
Quoted 4 lines
Cheers,
Richard
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
In reply to Bruce AshfieldQuoted 39 lines · Bruce Ashfield
There was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched.
This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user.
[YOCTO: #11878]
Signed-off-by Bruce Ashfield <[email protected]>--- meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/kernel-yocto.bbclass +3
-0@@ -143,6 +143,9 @@ do_kernel_metadata() { # expand kernel features into their full path equivalents bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then + bbfatal_log "Could not locate BSP definiton for ${KMACHINE}/${LINUX_KERNEL_TYPE}." + fi meta_dir=$(kgit --meta) # run1: pull all the configuration fragments, no matter where they come frommeta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0
-0
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b · line 7
Quoted 5 lines
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-1@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b DEPENDS = "git-native" -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c" +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83"
My builds last night of poky+meta-ti all failed with:
DEBUG: Running ... git -c core.fsyncobjectfiles=0 clone -s -n /OE/poky-master/downloads/git2/git.yoctoproject.org.yocto-kernel-tools.git/ /OE/poky-master/build/tmp/work/x86_64-linux/kern-tools-native/0.2+gitAUTOINC+0571411cc0-r12/git/
DEBUG: Running ... git -c core.fsyncobjectfiles=0 remote set-url origin git://git.yoctoproject.org/yocto-kernel-tools.git
DEBUG: Running ... git -c core.fsyncobjectfiles=0 checkout -B master 0571411cc033c11df7827508dd786876ce2f8c83
ERROR: Fetcher failure: Fetch command ... git -c core.fsyncobjectfiles=0 checkout -B master 0571411cc033c11df7827508dd786876ce2f8c83 failed with exit code 128, output:
fatal: reference is not a tree: 0571411cc033c11df7827508dd786876ce2f8c83
Quoted 11 lines
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0
-0PR = "r12" PV = "0.2+git${SRCPV}"Signature · 7 lines
2.5.0 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [PATCH 8/9] kernel-yocto: ensure that only valid BSPs are built
Quoted 48 lines · Denys Dmytriyenko
Quoted 39 lines · Bruce Ashfield
There was a bug in the search routines responsible for locating BSP definitions which returned a valid match if only the ktype matched.
This meant that someone looking for "qemux86foo" (which is an invalid definition) would potentially end up building "qemuarm" and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return code testing, we will now stop the build and report and error to the user.
[YOCTO: #11878]
Signed-off-by Bruce Ashfield <[email protected]>--- meta/classes/kernel-yocto.bbclass | 3 +++ meta/recipes-kernel/kern-tools/kern-tools-native_git.bb | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-)meta/classes/kernel-yocto.bbclass +3
-0@@ -143,6 +143,9 @@ do_kernel_metadata() { # expand kernel features into their full path equivalents bsp_definition=$(spp ${includes} --find -DKMACHINE=${KMACHINE} -DKTYPE=${LINUX_KERNEL_TYPE}) + if [ $? -ne 0 ] || [ -z "${bsp_definition}" ]; then + bbfatal_log "Could not locate BSP definiton for ${KMACHINE}/${LINUX_KERNEL_TYPE}." + fi meta_dir=$(kgit --meta) # run1: pull all the configuration fragments, no matter where they come frommeta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0
-0meta/recipes-kernel/kern-tools/kern-tools-native_git.bb LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b · line 7
Quoted 5 lines
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-1@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=a6c2fa8aef1b DEPENDS = "git-native" -SRCREV = "9cd2b626d652bec10c6bc75275b35bfee74d447c" +SRCREV = "0571411cc033c11df7827508dd786876ce2f8c83"My builds last night of poky+meta-ti all failed with:
Quoted 5 lines
DEBUG: Running ... git -c core.fsyncobjectfiles=0 clone -s -n /OE/poky-master/downloads/git2/git.yoctoproject.org.yocto-kernel-tools.git/ /OE/poky-master/build/tmp/work/x86_64-linux/kern-tools-native/0.2+gitAUTOINC+0571411cc0-r12/git/
DEBUG: Running ... git -c core.fsyncobjectfiles=0 remote set-url origingit://git.yoctoproject.org/yocto-kernel-tools.git
DEBUG: Running ... git -c core.fsyncobjectfiles=0 checkout -B master0571411cc033c11df7827508dd786876ce2f8c83
ERROR: Fetcher failure: Fetch command ... git -c core.fsyncobjectfiles=0 checkout -B master0571411cc033c11df7827508dd786876ce2f8c83failed with exit code 128, output:
fatal: reference is not a tree:0571411cc033c11df7827508dd786876ce2f8c83
I haven't seen this one, but I did just confirm manually that that SRCREV is in the upstream repo.
Did some sort of mirroring get in the way ?
Bruce
Quoted 13 lines
Quoted 13 lines
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0
-0PR = "r12" PV = "0.2+git${SRCPV}"Signature · 7 lines
2.5.0 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
PATCH 9/9 linux-yocto/4.10: CVE & misc fixes
In reply to Bruce AshfieldUpdating the 4.10 SRCREVs to import the following changes:
65370fa249e2 drm/vmwgfx: limit the number of mip levels in vmw_gb_surface_define_ioctl() 530ec12a0cb0 ACPICA: Namespace: fix operand cache leak
b1098b5bbded char: lp: fix possible integer overflow in lp_setup() 56ee0c7811e5 dccp/tcp: do not inherit mc_list from parent
9f6cbd022bba nfsd: encoders mustn't use unitialized values in error cases 084036ebc243 nfsd: fix undefined behavior in nfsd4_layout_verify 973f780eeaa6 xen-blkback: don't leak stack data via response ring 20c4b5015fea brcmfmac: fix possible buffer overflow in brcmf_cfg80211_mgmt_tx() 1dff0f28b490 ipx: call ipxitf_put() in ioctl error path
d666a8e60a45 mm: fix new crash in unmapped_area_topdown()
73d059ba1a17 mm: larger stack guard gap, between vmas
Which address the following CVEs:
CVE-2017-8890
CVE-2017-1000363
CVE-2017-11472
CVE-2017-7346
CVE-2017-1000380
CVE-2017-7541
CVE-2017-10911
--- meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb | 4 ++-- meta/recipes-kernel/linux/linux-yocto-tiny_4.10.bb | 4 ++-- meta/recipes-kernel/linux/linux-yocto_4.10.bb | 18 +++++++++--------- 3 files changed, 13 insertions(+), 13 deletions(-)
meta/recipes-kernel/linux/linux-yocto-rt_4.10.bb +2 -2
@@ -11,8 +11,8 @@ python () { raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it") } -SRCREV_machine ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_meta ?= "d6ece632214e3bee843e485487e5f0d6939630a8" +SRCREV_machine ?= "65370fa249e282e4ce69cf927c01898b4c16f261" +SRCREV_meta ?= "6ac2680ca4316fe111cddec37def7757843bbe86" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.10.git;branch=${KBRANCH};name=machine \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.10;destsuffix=${KMETA}"
meta/recipes-kernel/linux/linux-yocto-tiny_4.10.bb +2 -2
@@ -9,8 +9,8 @@ LINUX_VERSION ?= "4.10.17" KMETA = "kernel-meta" KCONF_BSP_AUDIT_LEVEL = "2" -SRCREV_machine ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_meta ?= "d6ece632214e3bee843e485487e5f0d6939630a8" +SRCREV_machine ?= "65370fa249e282e4ce69cf927c01898b4c16f261" +SRCREV_meta ?= "6ac2680ca4316fe111cddec37def7757843bbe86" PV = "${LINUX_VERSION}+git${SRCPV}"
meta/recipes-kernel/linux/linux-yocto_4.10.bb +9 -9
@@ -11,15 +11,15 @@ KBRANCH_qemux86 ?= "standard/base" KBRANCH_qemux86-64 ?= "standard/base" KBRANCH_qemumips64 ?= "standard/mti-malta64" -SRCREV_machine_qemuarm ?= "3926e386306fe0ae92feae45bc47e4c013daa1fc" -SRCREV_machine_qemuarm64 ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_machine_qemumips ?= "a038a5932f3be820f42d78f4e47850987ad72ce3" -SRCREV_machine_qemuppc ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_machine_qemux86 ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_machine_qemux86-64 ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_machine_qemumips64 ?= "b442c964432938cbe10c4cc578260353045af980" -SRCREV_machine ?= "6648a34e00c55a0634b39e661dd6ba14dd106473" -SRCREV_meta ?= "d6ece632214e3bee843e485487e5f0d6939630a8" +SRCREV_machine_qemuarm ?= "4c652d50c67050422da4621cc6421ecb86b31c31" +SRCREV_machine_qemuarm64 ?= "65370fa249e282e4ce69cf927c01898b4c16f261" +SRCREV_machine_qemumips ?= "0a632fa7f9615ad1b2488a300846a7e925e6591a" +SRCREV_machine_qemuppc ?= "65370fa249e282e4ce69cf927c01898b4c16f261" +SRCREV_machine_qemux86 ?= "65370fa249e282e4ce69cf927c01898b4c16f261" +SRCREV_machine_qemux86-64 ?= "65370fa249e282e4ce69cf927c01898b4c16f261" +SRCREV_machine_qemumips64 ?= "75c22c1be83bf7894af78a36b3e3c5af08ce4d7b" +SRCREV_machine ?= "65370fa249e282e4ce69cf927c01898b4c16f261" +SRCREV_meta ?= "6ac2680ca4316fe111cddec37def7757843bbe86" SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.10.git;name=machine;branch=${KBRANCH}; \ git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.10;destsuffix=${KMETA}"
Signature · 1 line
2.5.0
✗ patchtest: failure for kernel-yocto: consolidated pull request
In reply to Bruce Ashfield== Series Details ==
Series: kernel-yocto: consolidated pull request
Revision: 1
URL : https://patchwork.openembedded.org/series/8363/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures:
* Patch [8/9] kernel-yocto: ensure that only valid BSPs are built Issue Yocto Project bugzilla tag is not correctly formatted [test_bugzilla_entry_format] Suggested fix Specify bugzilla ID in commit description with format: "[YOCTO #<bugzilla ID>]"
If you believe any of these test results are incorrect, please reply to the mailing list ([email protected]) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...).
---
Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe
Quoted 35 lines · Bruce Ashfield
Hi all,
Here's the collected set of kernel changes that are ready for the M3 builds.
We have some kernel meta data changes:
kernel-yocto: configuration updates: x86 features linux-yocto/4.1: fix fsl-ls10xx sdhci
linux-yocto: add usb-net configs by defaultSome bug fixes:
kernel-yocto: ensure that only valid BSPs are built linux-yocto/4.10: CVE & misc fixes
And the important changes are the addition of the 4.12 kernel + libc headers
and the removal of the 4.1 kernel.I also have some -stable updates queued for the active kernel versions, but
they will come out once this series has made it into the tree, since I'm
trying to isolate any 4.12 issues from other -stable updates.I built and booted all the qemu targets for 4.12, and have built for core-image-sato, core-image-kernel-dev, glibc and muslc for all of the
architectures. My testing didn't pick up any regressions, but I was battling
some other build errors (non kernel related) during my testing, so I can
never be 100% sure.
Quoted 3 lines
I've sent patches to poky to remove/bump any references to the 4.1 kernel
.. if I've missed any, I'm sure people will shout.
I added an extra patch for the ones you missed in meta-yocto-bsp ;-)
Also, https://autobuilder.yocto.io/builders/build-appliance/builds/425/
steps/BuildImages_1/logs/stdio
Error:
Problem: conflicting requests
- nothing provides /bin/awk needed by kernel-devsrc-1.0-r0.0.qemux86_64
Cheers,
Richard
Quoted 40 lines · Richard Purdie
Quoted 35 lines · Bruce Ashfield
Hi all,
Here's the collected set of kernel changes that are ready for the M3 builds.
We have some kernel meta data changes:
kernel-yocto: configuration updates: x86 features linux-yocto/4.1: fix fsl-ls10xx sdhci
linux-yocto: add usb-net configs by defaultSome bug fixes:
kernel-yocto: ensure that only valid BSPs are built linux-yocto/4.10: CVE & misc fixes
And the important changes are the addition of the 4.12 kernel + libc headers
and the removal of the 4.1 kernel.I also have some -stable updates queued for the active kernel versions, but
they will come out once this series has made it into the tree, since I'm
trying to isolate any 4.12 issues from other -stable updates.I built and booted all the qemu targets for 4.12, and have built for core-image-sato, core-image-kernel-dev, glibc and muslc for all of the
architectures. My testing didn't pick up any regressions, but I was battling
some other build errors (non kernel related) during my testing, so I can
never be 100% sure.Quoted 3 lines
I've sent patches to poky to remove/bump any references to the 4.1 kernel
.. if I've missed any, I'm sure people will shout.
Quoted 9 lines
I added an extra patch for the ones you missed in meta-yocto-bsp ;-)
Also, https://autobuilder.yocto.io/builders/build-appliance/builds/425/
steps/BuildImages_1/logs/stdioError:
Problem: conflicting requests
- nothing provides/bin/awkneeded by kernel-devsrc-1.0-r0.0.qemux86_64
Hmm. I've built that exact combination on two different builders in the past week
and have never seen this.
How do I find out about the environment on that machine ? Because I'm not going
to be able to reproduce it here.
Bruce
Quoted 12 lines
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Quoted 56 lines · Bruce Ashfield
Quoted 42 lines · Richard Purdie
Quoted 35 lines · Bruce Ashfield
Hi all,
Here's the collected set of kernel changes that are ready for the M3 builds.
We have some kernel meta data changes:
kernel-yocto: configuration updates: x86 features linux-yocto/4.1: fix fsl-ls10xx sdhci
linux-yocto: add usb-net configs by defaultSome bug fixes:
kernel-yocto: ensure that only valid BSPs are built linux-yocto/4.10: CVE & misc fixes
And the important changes are the addition of the 4.12 kernel + libc headers
and the removal of the 4.1 kernel.I also have some -stable updates queued for the active kernel versions, but
they will come out once this series has made it into the tree, since I'm
trying to isolate any 4.12 issues from other -stable updates.I built and booted all the qemu targets for 4.12, and have built for core-image-sato, core-image-kernel-dev, glibc and muslc for all of the
architectures. My testing didn't pick up any regressions, but I was battling
some other build errors (non kernel related) during my testing, so I can
never be 100% sure.Quoted 3 lines
I've sent patches to poky to remove/bump any references to the 4.1 kernel
.. if I've missed any, I'm sure people will shout.I added an extra patch for the ones you missed in meta-yocto-bsp ;-)
Quoted 8 lines
Also, https://autobuilder.yocto.io/builders/build-appliance/builds/425/
steps/BuildImages_1/logs/stdio
<https://autobuilder.yocto.io/builders/build-appliance/builds/425/steps/BuildImages_1/logs/stdio>Error:
Problem: conflicting requests
- nothing provides/bin/awkneeded by kernel-devsrc-1.0-r0.0.qemux86_64
Quoted 8 lines
Hmm. I've built that exact combination on two different builders in the past week
and have never seen this.How do I find out about the environment on that machine ? Because I'm not going
to be able to reproduce it here.
A little bit more information. Saul fixed this earlier this year, and I'm still carrying
a patch that ensures that /usr/bin/awk is in the ver_linux script instead of /bin/awk.
That fix used to satisfy a similar requirement.
That being said, I did notice that Saul's change was accepted upstream and the
patch I'm carrying is not correctly applied (but it should be an invalid patch, not
a reference to /bin/awk).
I've fixed that patch, and am building the build-appliance image now.
I will have a new set of SRCREVs for linux-yocto-4.12, but I can't say if they'll
fix the particular issue that the autobuilder is seeing.
Bruce
Quoted 23 lines
Bruce
Quoted 12 lines
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
Quoted 21 lines · Bruce Ashfield
Here's the collected set of kernel changes that are ready for the M3 builds.
We have some kernel meta data changes:
kernel-yocto: configuration updates: x86 features linux-yocto/4.1: fix fsl-ls10xx sdhci
linux-yocto: add usb-net configs by defaultSome bug fixes:
kernel-yocto: ensure that only valid BSPs are built linux-yocto/4.10: CVE & misc fixes
And the important changes are the addition of the 4.12 kernel + libc headers and the removal of the 4.1 kernel.
I also have some -stable updates queued for the active kernel versions, but they will come out once this series has made it into the tree, since I'm trying to isolate any 4.12 issues from other -stable updates.
Quoted 8 lines
I built and booted all the qemu targets for 4.12, and have built for core-image-sato, core-image-kernel-dev, glibc and muslc for all of the architectures. My testing didn't pick up any regressions, but I was battling some other build errors (non kernel related) during my testing, so I can never be 100% sure.
I've sent patches to poky to remove/bump any references to the 4.1 kernel .. if I've missed any, I'm sure people will shout.
Thanks for the other fix, not got that tested yet as builds are still ongoing. However there appears to be a perf issue:
https://autobuilder.yocto.io/builders/nightly-deb-non-deb/builds/429/steps/BuildImages/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/builds/77/steps/BuildImages/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/builds/77/steps/BuildImages_1/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/builds/77/steps/BuildImages_2/logs/stdio
[and so on]
Cheers,
Richard
Quoted 31 lines · Richard Purdie
Quoted 21 lines · Bruce Ashfield
Here's the collected set of kernel changes that are ready for the M3 builds.
We have some kernel meta data changes:
kernel-yocto: configuration updates: x86 features linux-yocto/4.1: fix fsl-ls10xx sdhci
linux-yocto: add usb-net configs by defaultSome bug fixes:
kernel-yocto: ensure that only valid BSPs are built linux-yocto/4.10: CVE & misc fixes
And the important changes are the addition of the 4.12 kernel + libc headers and the removal of the 4.1 kernel.
I also have some -stable updates queued for the active kernel versions, but they will come out once this series has made it into the tree, since I'm trying to isolate any 4.12 issues from other -stable updates.
Quoted 8 lines
I built and booted all the qemu targets for 4.12, and have built for core-image-sato, core-image-kernel-dev, glibc and muslc for all of the architectures. My testing didn't pick up any regressions, but I was battling some other build errors (non kernel related) during my testing, so I can never be 100% sure.
I've sent patches to poky to remove/bump any references to the 4.1 kernel .. if I've missed any, I'm sure people will shout.
Quoted 9 lines
Thanks for the other fix, not got that tested yet as builds are still ongoing. However there appears to be a perf issue:
https://autobuilder.yocto.io/builders/nightly-deb-non-deb/builds/429/steps/BuildImages/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/builds/77/steps/BuildImages/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/builds/77/steps/BuildImages_1/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/builds/77/steps/BuildImages_2/logs/stdio
[and so on]
Again, I'm not going to be much good on fixing this.
I of course have built (and run perf on target) for all the architectures or I never would have sent the pull request.
I'll see if I can find something wrong on what my building was producing, but otherwise, I have no way to reproduce it.
Bruce
Quoted 6 lines
Cheers,
Richard
Quoted 31 lines · Richard Purdie
Quoted 21 lines · Bruce Ashfield
Here's the collected set of kernel changes that are ready for the M3 builds.
We have some kernel meta data changes:
kernel-yocto: configuration updates: x86 features linux-yocto/4.1: fix fsl-ls10xx sdhci
linux-yocto: add usb-net configs by defaultSome bug fixes:
kernel-yocto: ensure that only valid BSPs are built linux-yocto/4.10: CVE & misc fixes
And the important changes are the addition of the 4.12 kernel + libc headers and the removal of the 4.1 kernel.
I also have some -stable updates queued for the active kernel versions, but they will come out once this series has made it into the tree, since I'm trying to isolate any 4.12 issues from other -stable updates.
Quoted 8 lines
I built and booted all the qemu targets for 4.12, and have built for core-image-sato, core-image-kernel-dev, glibc and muslc for all of the architectures. My testing didn't pick up any regressions, but I was battling some other build errors (non kernel related) during my testing, so I can never be 100% sure.
I've sent patches to poky to remove/bump any references to the 4.1 kernel .. if I've missed any, I'm sure people will shout.
Quoted 9 lines
Thanks for the other fix, not got that tested yet as builds are still ongoing. However there appears to be a perf issue:
https://autobuilder.yocto.io/builders/nightly-deb-non-deb/builds/429/steps/BuildImages/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/builds/77/steps/BuildImages/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/builds/77/steps/BuildImages_1/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/builds/77/steps/BuildImages_2/logs/stdio
[and so on]
Aha. There's a difference in the clibrary that I was using. I'll have a closer look once my switch over and build gets going.
Bruce
Quoted 6 lines
Cheers,
Richard
Quoted 56 lines · Bruce Ashfield
Quoted 45 lines · Richard Purdie
Quoted 36 lines · Bruce Ashfield
Here's the collected set of kernel changes that are ready for the M3
builds.We have some kernel meta data changes:
kernel-yocto: configuration updates: x86 features linux-yocto/4.1: fix fsl-ls10xx sdhci
linux-yocto: add usb-net configs by defaultSome bug fixes:
kernel-yocto: ensure that only valid BSPs are built linux-yocto/4.10: CVE & misc fixes
And the important changes are the addition of the 4.12 kernel + libc headers
and the removal of the 4.1 kernel.I also have some -stable updates queued for the active kernel versions, but
they will come out once this series has made it into the tree, since I'm
trying to isolate any 4.12 issues from other -stable updates.I built and booted all the qemu targets for 4.12, and have built for
core-image-sato, core-image-kernel-dev, glibc and muslc for all of the
architectures. My testing didn't pick up any regressions, but I was battling
some other build errors (non kernel related) during my testing, so I can
never be 100% sure.Quoted 3 lines
I've sent patches to poky to remove/bump any references to the 4.1 kernel
.. if I've missed any, I'm sure people will shout.Thanks for the other fix, not got that tested yet as builds are still
ongoing. However there appears to be a perf issue:Quoted 10 lines
https://autobuilder.yocto.io/builders/nightly-deb-non-deb/builds/42
9/steps/BuildImages/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/build
s/77/steps/BuildImages/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/build
s/77/steps/BuildImages_1/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/build
s/77/steps/BuildImages_2/logs/stdio
[and so on]
Quoted 2 lines
Aha. There's a difference in the clibrary that I was using. I'll have a closer look once my switch over and build gets going.
Thanks, I think you got that one but the /bin/awk issue remained after your changes. Its easy to reproduce with "bitbake core-image-sato-sdk", or IMAGE_INSTALL_append = " kernel-devsrc". I ended up with this change to fix it:
which I appreciate you won't like but it illustrates the problem. Any preference on what to do with that patch?
We do also have a boot test issue on mips64:
and mips:
I assume we just have to whitelist that error message?
Cheers,
Richard
Quoted 57 lines · Richard Purdie
Quoted 56 lines · Bruce Ashfield
Quoted 55 lines · Richard Purdie
Quoted 36 lines · Bruce Ashfield
Here's the collected set of kernel changes that are ready for the M3
builds.We have some kernel meta data changes:
kernel-yocto: configuration updates: x86 features linux-yocto/4.1: fix fsl-ls10xx sdhci
linux-yocto: add usb-net configs by defaultSome bug fixes:
kernel-yocto: ensure that only valid BSPs are built linux-yocto/4.10: CVE & misc fixes
And the important changes are the addition of the 4.12 kernel + libc headers
and the removal of the 4.1 kernel.I also have some -stable updates queued for the active kernel versions, but
they will come out once this series has made it into the tree, since I'm
trying to isolate any 4.12 issues from other -stable updates.I built and booted all the qemu targets for 4.12, and have built for
core-image-sato, core-image-kernel-dev, glibc and muslc for all of the
architectures. My testing didn't pick up any regressions, but I was battling
some other build errors (non kernel related) during my testing, so I can
never be 100% sure.Quoted 3 lines
I've sent patches to poky to remove/bump any references to the 4.1 kernel
.. if I've missed any, I'm sure people will shout.Thanks for the other fix, not got that tested yet as builds are still
ongoing. However there appears to be a perf issue:https://autobuilder.yocto.io/builders/nightly-deb-non-deb/builds/42
9/steps/BuildImages/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/build
s/77/steps/BuildImages/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/build
s/77/steps/BuildImages_1/logs/stdio
https://autobuilder.yocto.io/builders/nightly-packagemanagers/build
s/77/steps/BuildImages_2/logs/stdio
[and so on]
Quoted 7 lines
Quoted 2 lines
Aha. There's a difference in the clibrary that I was using. I'll have a closer look once my switch over and build gets going.
Thanks, I think you got that one but the
/bin/awkissue remained after your changes. Its easy to reproduce with "bitbake core-image-sato-sdk", orIMAGE_INSTALL_append= " kernel-devsrc". I ended up with this change to fix it:
Yah, I noticed all of those references as well. Saul had dealt with the one that hit us before, but I wasn't able to trigger any installs of the other parts in the images I built .. so they were being left be for now, just to keep our footprint low.
Quoted 5 lines
which I appreciate you won't like but it illustrates the problem. Any preference on what to do with that patch?
I can merge it directly into linux-yocto, since that is what we did with Saul's change before, and at the same time, we can submit it upstream and drop it next release.
Quoted 10 lines
We do also have a boot test issue on mips64:
and mips:
I assume we just have to whitelist that error message?
Yep. It is something that has been around for a while and comes from the general open firmware support. It is a warning only (obviously) and can safely be ignored. We keep the OF support on for compatibility so live with a few warnings like that.
Bruce
Quoted 5 lines
Cheers,
Richard
Quoted 19 lines · Bruce Ashfield
Quoted 8 lines · Richard Purdie
Thanks, I think you got that one but the/bin/awkissue remained after
your changes. Its easy to reproduce with "bitbake core-image-sato- sdk",
orIMAGE_INSTALL_append= " kernel-devsrc". I ended up with this change
to fix it:Yah, I noticed all of those references as well. Saul had dealt with the one that hit us before, but I wasn't able to trigger any installs of the other parts in the images I built .. so they were being left be for now, just to keep our footprint low.
Quoted 5 lines
http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=
a28acfa6c5890df4f5cb09962ef0c53837ac3b37
Quoted 6 lines
Quoted 3 lines
which I appreciate you won't like but it illustrates the problem. Any
preference on what to do with that patch?I can merge it directly into linux-yocto, since that is what we did with Saul's change before, and at the same time, we can submit it upstream and drop it next release.
Ok, Should I merge my patch for now and you and then deal with it in due course or do you want to do that directly?
I can take care of the mips issue but we have one final problem:
"oe-selftest -r runqemu.RunqemuTests.test_boot_machine_iso"
is failing, it works with 4.10, fails with 4.12. Did some key config option for booting isos go missing?
Cheers,
Richard
Quoted 23 lines · Richard Purdie
Quoted 22 lines · Bruce Ashfield
Quoted 8 lines · Richard Purdie
Thanks, I think you got that one but the
/bin/awkissue remained after
your changes. Its easy to reproduce with "bitbake core-image-sato- sdk",
orIMAGE_INSTALL_append= " kernel-devsrc". I ended up with this change
to fix it:Yah, I noticed all of those references as well. Saul had dealt with the one that hit us before, but I wasn't able to trigger any installs of the other parts in the images I built .. so they were being left be for now, just to keep our footprint low.
Quoted 8 lines
http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=
a28acfa6c5890df4f5cb09962ef0c53837ac3b37which I appreciate you won't like but it illustrates the problem. Any
preference on what to do with that patch?
Quoted 6 lines
Quoted 3 lines
I can merge it directly into linux-yocto, since that is what we did with Saul's change before, and at the same time, we can submit it upstream and drop it next release.
Ok, Should I merge my patch for now and you and then deal with it in due course or do you want to do that directly?
I can send you a v4 of the 4.12 patch in the next half an hour, that's easiest for me to do.
.. but if it isn't for you, go ahead and do the merge and I'll sort it out in a follow up.
Quoted 7 lines
I can take care of the mips issue but we have one final problem:
"oe-selftest -r runqemu.RunqemuTests.test_boot_machine_iso"
is failing, it works with 4.10, fails with 4.12. Did some key config option for booting isos go missing?
Not that I'm aware of, but I admit that I've never done any ISO booting of the images so wouldn't see it.
I'll diff the configs here and see if anything jumps out. Otherwise, I'll do a boot test myself and debug from there.
Bruce
Quoted 5 lines
Cheers,
Richard
Quoted 5 lines · Bruce Ashfield
I can send you a v4 of the 4.12 patch in the next half an hour, that's easiest for me to do.
.. but if it isn't for you, go ahead and do the merge and I'll sort it out in a follow up.
The above works, I'm still trying to get to the bottom of the other issues that are going on.
Quoted 4 lines
Quoted 4 lines
I can take care of the mips issue but we have one final problem:
"oe-selftest -r runqemu.RunqemuTests.test_boot_machine_iso"
Quoted 8 lines
Quoted 3 lines
is failing, it works with 4.10, fails with 4.12. Did some key config
option for booting isos go missing?Not that I'm aware of, but I admit that I've never done any ISO booting of the images so wouldn't see it.
I'll diff the configs here and see if anything jumps out. Otherwise, I'll do a boot test myself and debug from there.
After running the failing test case, I was able to manually boot with:
tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -cdrom tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20170822154904.iso -no-reboot -vga vmware -show-cursor -usb -device usb-tablet -device virtio-rng-pci -nographic -cpu core2duo -m 256
and then quickly "down, enter" to select the serial console option which gave me this:
[ 4.980303] netconsole: network logging started
[ 4.980981] rtc_cmos 00:00: setting system clock to 2017-08-22 15:56:12 UTC (1503417372)
[ 5.036130] Freeing unused kernel memory: 1440K
[ 5.036320] Write protecting the kernel read-only data: 14336k
[ 5.039206] Freeing unused kernel memory: 864K
[ 5.072281] Freeing unused kernel memory: 1232K
[ 5.173842] usb 1-1: new full-speed USB device number 2 using uhci_hcd
starting version 234
[ 5.349596] input: QEMU QEMU USB Tablet as /devices/pci0000:00/0000:00:01.2/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input4
[ 5.361353] hid-generic 0003:0627:0001.0001: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.2-1/input0
[ 5.504201] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
[ 6.408140] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 6.408651] IP: ide_cdrom_prep_fn+0x63/0x180
[ 6.408802] PGD beed067
[ 6.408834] P4D beed067
[ 6.408935] PUD 0
[ 6.409028]
[ 6.409251] Oops: 0002 [#1] PREEMPT SMP
[ 6.409524] Modules linked in:
[ 6.409811] CPU: 0 PID: 117 Comm: udevd Not tainted 4.12.7-yocto-standard #4
[ 6.410012] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
[ 6.410399] task: ffff9366cbd87080 task.stack: ffff9778c0304000
[ 6.410613] RIP: 0010:ide_cdrom_prep_fn+0x63/0x180
[ 6.410749] RSP: 0018:ffff9778c0307ad8 EFLAGS: 00000002
[ 6.410902] RAX: 0000000000000002 RBX: ffff9366cc3ef800 RCX: 0000000000000000
[ 6.411089] RDX: 0000000000000000 RSI: ffff9366cbf1ec00 RDI: 000000000000a1fc
[ 6.411318] RBP: ffff9778c0307ad8 R08: 0000000000000000 R09: 0000000000000001
[ 6.411510] R10: 0000000000000020 R11: 0000000020112a00 R12: ffff9366cbf1ec00
[ 6.411717] R13: 00000000ffffff87 R14: 00000000fffffffb R15: 0000000000000000
[ 6.411938] FS: 00007fd6fa79e300(0000) GS:ffff9366cf200000(0000) knlGS:0000000000000000
[ 6.412153] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6.412351] CR2: 0000000000000000 CR3: 000000000beec000 CR4: 00000000000006f0
[ 6.412686] Call Trace:
[ 6.413793] blk_peek_request+0x189/0x2d0
[ 6.414010] blk_fetch_request+0x12/0x30
[ 6.414142] ? _raw_spin_unlock_irq+0x23/0x30
[ 6.414276] do_ide_request+0x37d/0x660
[ 6.414382] ? cfq_group_service_tree_add+0x94/0xc0
[ 6.414559] ? cfq_service_tree_add+0x258/0x300
[ 6.414695] ? ktime_get+0x40/0xa0
[ 6.414800] __blk_run_queue+0x33/0x40
[ 6.414908] queue_unplugged+0x2f/0xc0
[ 6.415017] blk_flush_plug_list+0x1f9/0x240
[ 6.415138] blk_finish_plug+0x2c/0x40
[ 6.415255] __do_page_cache_readahead+0x1bd/0x260
[ 6.415408] force_page_cache_readahead+0xb5/0x110
[ 6.415550] ? force_page_cache_readahead+0xb5/0x110
[ 6.415687] page_cache_sync_readahead+0x3f/0x50
[ 6.415815] generic_file_read_iter+0x54b/0x700
[ 6.415965] blkdev_read_iter+0x35/0x40
[ 6.416085] __vfs_read+0xbf/0x110
[ 6.416182] vfs_read+0x8e/0x110
[ 6.416279] SyS_read+0x46/0xb0
[ 6.416369] ? SyS_lseek+0x87/0xb0
[ 6.416469] entry_SYSCALL_64_fastpath+0x1a/0xa5
[ 6.416747] RIP: 0033:0x7fd6f9b06891
[ 6.416854] RSP: 002b:00007fff59e50a08 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[ 6.417057] RAX: ffffffffffffffda RBX: 00007fff59e4f950 RCX: 00007fd6f9b06891
[ 6.417248] RDX: 0000000000000200 RSI: 00007fff59e50ac0 RDI: 000000000000000c
[ 6.417439] RBP: 00007fff59e4f950 R08: 0000000000000000 R09: 00007fd6f98751c0
[ 6.417643] R10: 000000000000006d R11: 0000000000000246 R12: 00007fff59e509d8
[ 6.417832] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 6.418057] Code: 2f 01 00 00 b9 01 00 00 00 bf 01 00 00 00 48 8b 46 60 48 99 48 f7 ff 48 89 c7 8b 46 58 31 d2 c1 e8 09 f7 f1 48 8b 8e 50 01 00 00 <48> c7 01 00 00 00 00 48 c7 41 08 00 00 00 00 f6 46 44 01 48 8b [ 6.418825] RIP: ide_cdrom_prep_fn+0x63/0x180 RSP: ffff9778c0307ad8
[ 6.419017] CR2: 0000000000000000
[ 6.419324] ---[ end trace dd02c5282d34fc7b ]---
[ 6.419558] note: udevd[117] exited with preempt_count 1
Waiting for removable media...
Something in the IDE CDROM driver?
Cheers,
Richard
Quoted 9 lines · Richard Purdie
Quoted 5 lines · Bruce Ashfield
I can send you a v4 of the 4.12 patch in the next half an hour, that's easiest for me to do.
.. but if it isn't for you, go ahead and do the merge and I'll sort it out in a follow up.
The above works, I'm still trying to get to the bottom of the other issues that are going on.
Patch sent as a v4 (although I now realize I forgot to put v4 in the subject, only in the summary).
Quoted 88 lines
Quoted 5 lines
Quoted 5 lines
I can take care of the mips issue but we have one final problem:
"oe-selftest -r runqemu.RunqemuTests.test_boot_machine_iso"
Quoted 8 lines
Quoted 3 lines
is failing, it works with 4.10, fails with 4.12. Did some key config
option for booting isos go missing?Not that I'm aware of, but I admit that I've never done any ISO booting of the images so wouldn't see it.
I'll diff the configs here and see if anything jumps out. Otherwise, I'll do a boot test myself and debug from there.
After running the failing test case, I was able to manually boot with:
tmp/work/x86_64-linux/qemu-helper-native/1.0-r1/recipe-sysroot-native/usr/bin//qemu-system-x86_64 -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:02 -netdev tap,id=net0,ifname=tap0,script=no,downscript=no -cdrom tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20170822154904.iso -no-reboot -vga vmware -show-cursor -usb -device usb-tablet -device virtio-rng-pci -nographic -cpu core2duo -m 256
and then quickly "down, enter" to select the serial console option which gave me this:
[ 4.980303] netconsole: network logging started [ 4.980981] rtc_cmos 00:00: setting system clock to 2017-08-22 15:56:12 UTC (1503417372) [ 5.036130] Freeing unused kernel memory: 1440K [ 5.036320] Write protecting the kernel read-only data: 14336k [ 5.039206] Freeing unused kernel memory: 864K [ 5.072281] Freeing unused kernel memory: 1232K [ 5.173842] usb 1-1: new full-speed USB device number 2 using uhci_hcd starting version 234 [ 5.349596] input: QEMU QEMU USB Tablet as /devices/pci0000:00/0000:00:01.2/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input4 [ 5.361353] hid-generic 0003:0627:0001.0001: input: USB HID v0.01 Mouse [QEMU QEMU USB Tablet] on usb-0000:00:01.2-1/input0 [ 5.504201] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3 [ 6.408140] BUG: unable to handle kernel NULL pointer dereference at (null) [ 6.408651] IP: ide_cdrom_prep_fn+0x63/0x180 [ 6.408802] PGD beed067 [ 6.408834] P4D beed067 [ 6.408935] PUD 0 [ 6.409028] [ 6.409251] Oops: 0002 [#1] PREEMPT SMP [ 6.409524] Modules linked in: [ 6.409811] CPU: 0 PID: 117 Comm: udevd Not tainted 4.12.7-yocto-standard #4 [ 6.410012] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014 [ 6.410399] task: ffff9366cbd87080 task.stack: ffff9778c0304000 [ 6.410613] RIP: 0010:ide_cdrom_prep_fn+0x63/0x180 [ 6.410749] RSP: 0018:ffff9778c0307ad8 EFLAGS: 00000002 [ 6.410902] RAX: 0000000000000002 RBX: ffff9366cc3ef800 RCX: 0000000000000000 [ 6.411089] RDX: 0000000000000000 RSI: ffff9366cbf1ec00 RDI: 000000000000a1fc [ 6.411318] RBP: ffff9778c0307ad8 R08: 0000000000000000 R09: 0000000000000001 [ 6.411510] R10: 0000000000000020 R11: 0000000020112a00 R12: ffff9366cbf1ec00 [ 6.411717] R13: 00000000ffffff87 R14: 00000000fffffffb R15: 0000000000000000 [ 6.411938] FS: 00007fd6fa79e300(0000) GS:ffff9366cf200000(0000) knlGS:0000000000000000 [ 6.412153] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6.412351] CR2: 0000000000000000 CR3: 000000000beec000 CR4: 00000000000006f0 [ 6.412686] Call Trace: [ 6.413793] blk_peek_request+0x189/0x2d0 [ 6.414010] blk_fetch_request+0x12/0x30 [ 6.414142] ? _raw_spin_unlock_irq+0x23/0x30 [ 6.414276] do_ide_request+0x37d/0x660 [ 6.414382] ? cfq_group_service_tree_add+0x94/0xc0 [ 6.414559] ? cfq_service_tree_add+0x258/0x300 [ 6.414695] ? ktime_get+0x40/0xa0 [ 6.414800] __blk_run_queue+0x33/0x40 [ 6.414908] queue_unplugged+0x2f/0xc0 [ 6.415017] blk_flush_plug_list+0x1f9/0x240 [ 6.415138] blk_finish_plug+0x2c/0x40 [ 6.415255] __do_page_cache_readahead+0x1bd/0x260 [ 6.415408] force_page_cache_readahead+0xb5/0x110 [ 6.415550] ? force_page_cache_readahead+0xb5/0x110 [ 6.415687] page_cache_sync_readahead+0x3f/0x50 [ 6.415815] generic_file_read_iter+0x54b/0x700 [ 6.415965] blkdev_read_iter+0x35/0x40 [ 6.416085] __vfs_read+0xbf/0x110 [ 6.416182] vfs_read+0x8e/0x110 [ 6.416279] SyS_read+0x46/0xb0 [ 6.416369] ? SyS_lseek+0x87/0xb0 [ 6.416469] entry_SYSCALL_64_fastpath+0x1a/0xa5 [ 6.416747] RIP: 0033:0x7fd6f9b06891 [ 6.416854] RSP: 002b:00007fff59e50a08 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 6.417057] RAX: ffffffffffffffda RBX: 00007fff59e4f950 RCX: 00007fd6f9b06891 [ 6.417248] RDX: 0000000000000200 RSI: 00007fff59e50ac0 RDI: 000000000000000c [ 6.417439] RBP: 00007fff59e4f950 R08: 0000000000000000 R09: 00007fd6f98751c0 [ 6.417643] R10: 000000000000006d R11: 0000000000000246 R12: 00007fff59e509d8 [ 6.417832] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 6.418057] Code: 2f 01 00 00 b9 01 00 00 00 bf 01 00 00 00 48 8b 46 60 48 99 48 f7 ff 48 89 c7 8b 46 58 31 d2 c1 e8 09 f7 f1 48 8b 8e 50 01 00 00 <48> c7 01 00 00 00 00 48 c7 41 08 00 00 00 00 f6 46 44 01 48 8b [ 6.418825] RIP: ide_cdrom_prep_fn+0x63/0x180 RSP: ffff9778c0307ad8 [ 6.419017] CR2: 0000000000000000 [ 6.419324] ---[ end trace dd02c5282d34fc7b ]--- [ 6.419558] note: udevd[117] exited with preempt_count 1
Quoted 3 lines
Waiting for removable media...
Something in the IDE CDROM driver?
I keep getting sent changes to drop IDE support completely, but they aren't in play here, I'm still waiting on a 4.10 linux-yocto to configure so I can diff the .configs and fire up some comparison boot tests.
Bruce
Quoted 5 lines
Cheers,
Richard
Quoted 7 lines · Bruce Ashfield
Quoted 6 lines · Richard Purdie
Quoted 4 lines · Bruce Ashfield
I can send you a v4 of the 4.12 patch in the next half an hour, that's easiest for me to do.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
.. but if it isn't for you, go ahead and do the merge and I'll sort it out in a follow up.
The above works, I'm still trying to get to the bottom of the other issues that are going on.
Patch sent as a v4 (although I now realize I forgot to put v4 in the subject, only in the summary).
Thanks, I'll pull that into subsequent test runs.
Quoted 5 lines
Quoted 1 line
Something in the IDE CDROM driver?
I keep getting sent changes to drop IDE support completely, but they aren't in play here, I'm still waiting on a 4.10 linux-yocto to configure so I can diff the .configs and fire up some comparison boot tests.
I did diff the configs and nothing jumped out to me at least, CONFIG_INITRAMFS_COMPRESSION=".gz" went missing but doesn't look relevant as it only affects built in initramfs afaict.
Cheers,
Richard
Quoted 18 lines · Richard Purdie
Quoted 7 lines · Bruce Ashfield
Quoted 6 lines · Richard Purdie
Quoted 4 lines · Bruce Ashfield
I can send you a v4 of the 4.12 patch in the next half an hour, that's easiest for me to do.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
.. but if it isn't for you, go ahead and do the merge and I'll sort it out in a follow up.
The above works, I'm still trying to get to the bottom of the other issues that are going on.
Patch sent as a v4 (although I now realize I forgot to put v4 in the subject, only in the summary).
Thanks, I'll pull that into subsequent test runs.
Quoted 1 line
Quoted 1 line
Something in the IDE CDROM driver?
Quoted 8 lines
Quoted 4 lines
I keep getting sent changes to drop IDE support completely, but they aren't in play here, I'm still waiting on a 4.10 linux-yocto to configure so I can diff the .configs and fire up some comparison boot tests.
I did diff the configs and nothing jumped out to me at least,
CONFIG_INITRAMFS_COMPRESSION=".gz" went missing but doesn't look relevant as it only affects built in initramfs afaict.
Likewise, I'm seeing only noise in the diff (i.e. new selected options) and nothing that should break this.
Could be a valid issue with the driver. I'm onto some boot testing now.
Bruce
Quoted 6 lines
Cheers,
Richard
Quoted 18 lines · Richard Purdie
Quoted 7 lines · Bruce Ashfield
Quoted 6 lines · Richard Purdie
Quoted 4 lines · Bruce Ashfield
I can send you a v4 of the 4.12 patch in the next half an hour, that's easiest for me to do.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
.. but if it isn't for you, go ahead and do the merge and I'll sort it out in a follow up.
The above works, I'm still trying to get to the bottom of the other issues that are going on.
Patch sent as a v4 (although I now realize I forgot to put v4 in the subject, only in the summary).
Thanks, I'll pull that into subsequent test runs.
Quoted 1 line
Quoted 1 line
Something in the IDE CDROM driver?
Quoted 8 lines
Quoted 4 lines
I keep getting sent changes to drop IDE support completely, but they aren't in play here, I'm still waiting on a 4.10 linux-yocto to configure so I can diff the .configs and fire up some comparison boot tests.
I did diff the configs and nothing jumped out to me at least,
CONFIG_INITRAMFS_COMPRESSION=".gz" went missing but doesn't look relevant as it only affects built in initramfs afaict.
I am seeing the same thing, and can't see anything obvious.
I'm now doing a git bisect between 4.10 and 4.12.
Bruce
Quoted 6 lines
Cheers,
Richard
Quoted 18 lines · Richard Purdie
Quoted 7 lines · Bruce Ashfield
Quoted 6 lines · Richard Purdie
Quoted 4 lines · Bruce Ashfield
I can send you a v4 of the 4.12 patch in the next half an hour, that's easiest for me to do.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
.. but if it isn't for you, go ahead and do the merge and I'll sort it out in a follow up.
The above works, I'm still trying to get to the bottom of the other issues that are going on.
Patch sent as a v4 (although I now realize I forgot to put v4 in the subject, only in the summary).
Thanks, I'll pull that into subsequent test runs.
Quoted 1 line
Quoted 1 line
Something in the IDE CDROM driver?
Quoted 8 lines
Quoted 4 lines
I keep getting sent changes to drop IDE support completely, but they aren't in play here, I'm still waiting on a 4.10 linux-yocto to configure so I can diff the .configs and fire up some comparison boot tests.
I did diff the configs and nothing jumped out to me at least,
CONFIG_INITRAMFS_COMPRESSION=".gz" went missing but doesn't look relevant as it only affects built in initramfs afaict.
I found the commit that is causing the problem (after three hours of bisecting). That's the good news. The bad news is it isn't something I can revert .. or easily fix, since the commit is large and is pretty much tree wide. There's a lot of commits stacked on top if that change, so it can't be reverted.
------------
commit 82ed4db499b8598f16f8871261bff088d6b0597f
Author: Christoph Hellwig <[email protected]> Date: Fri Jan 27 09:46:29 2017 +0100
block: split scsi_request out of struct request
And require all drivers that want to support BLOCK_PC to allocate it as the first thing of their private data. To support this the legacy IDE and BSG code is switched to set cmd_size on their queues to let the block layer allocate the additional space.
---------
I was able to boot with the following in the command line:
-drive file=tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64-20170822200708.iso,if=virtio,media=cdrom
--------
IMHO we need to stop using the ancient IDE support, since it continually is broken (not usually this badly .. but often in more subtle ways).
So switching to a virtio backed CDROM, while the issue is reported upstream is probably the best bet.
Bruce
Quoted 6 lines
Cheers,
Richard
Quoted 37 lines · Bruce Ashfield
On 08/22/2017 12:07 PM, Richard Purdie wrote:
I found the commit that is causing the problem (after three hours of bisecting). That's the good news. The bad news is it isn't something
I can revert .. or easily fix, since the commit is large and is pretty
much tree wide. There's a lot of commits stacked on top if that change,
so it can't be reverted.------------
commit
82ed4db499b8598f16f8871261bff088d6b0597f
Author: Christoph Hellwig <[email protected]>
Date: Fri Jan 27 09:46:29 2017 +0100block: split
scsi_requestout of struct requestAnd require all drivers that want to support
BLOCK_PCto allocate it
as the first thing of their private data. To support this the legacy
IDE and BSG code is switched to setcmd_sizeon their queues to let
the block layer allocate the additional space.Signed-off-by Christoph Hellwig <[email protected]>Signed-off-by Jens Axboe <[email protected]>---------
I was able to boot with the following in the command line:
-drive file=tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64- 20170822200708.iso,if=virtio,media=cdrom
Quoted 8 lines
--------
IMHO we need to stop using the ancient IDE support, since it continually
is broken (not usually this badly .. but often in more subtle ways).So switching to a virtio backed CDROM, while the issue is reported upstream is probably the best bet.
That seems reasonable to me and should be a simple change to the runqemu script. The hint above should let me test that so I'll try and and see how the builds work out. Thanks for the help in figuring a workaround!
Cheers,
Richard