[PATCH 0/5] linux-yocto: consolidated pull request

[PATCH 0/5] linux-yocto: consolidated pull request

[Bruce Ashfield]

Here is the latest consolidated pull request for the supported linux-yocto
kernels.

 - We have a refresh of the 3.14-rt support
 - bluetooh configuration changes for common-pc/qemux86
 - braswell BSP features and fixes
 - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).

I've built and booted these on my local machines and qemu, and
everything was sane.

The -dev kernel obviously isn't something for deployment yet, but
it builds, and forms the base for follow up config changes, features
and development work. I built and booted core-image-kernel dev with
the 4.1 changes in place.

Cheers,

Bruce

The following changes since commit db409697db2ea0931cdcd2015d089b6b0ea39bbb:

  bitbake: bitbake: reset build mtime cache before the build (2015-04-29 10:59:54 +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 (5):
  linux-yocto/3.14: refresh -rt support
  linux-yocto: add core bluetooth support to qemux86* and common-pc*
  linux-yocto/3.19: Braswell support and bug fixes
  perf: fix build (and feature tests) for 4.1-rcX
  linux-yocto-dev: introduce 4.1-rc development kernel

 meta/recipes-kernel/linux/linux-yocto-dev.bb       |  2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb |  4 ++--
 meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb |  4 ++--
 meta/recipes-kernel/linux/linux-yocto_3.14.bb      | 18 +++++++++---------
 meta/recipes-kernel/linux/linux-yocto_3.19.bb      | 18 +++++++++---------
 meta/recipes-kernel/perf/perf.bb                   |  3 +++
 7 files changed, 29 insertions(+), 26 deletions(-)

-- 
2.1.0

[PATCH 1/5] linux-yocto/3.14: refresh -rt support

[Bruce Ashfield]

Paul Gortmaker refreshed the 3.14-rt support to the latest rt stable
content.

With these SRCREV bumps, the 3.14 LTSI kernel is now at -rt37.

   91dc6afcecd4 rt: bump localversion from 32 to 37
   e69f7430b620 rt: bump localversion to 32
   c060800318e4 netpoll: guard the access to dev->npinfo with rcu_read_lock/unlock_bh() for CONFIG_PREEMPT_RT_FULL=y
   833c21beba79 Revert "timers: do not raise softirq unconditionally"
   6c9337ff352c fs,btrfs: fix rt deadlock on extent_buffer->lock
   2d542663bfb9 staging: Mark rtl8821ae as broken
   988e4701df83 timers: Reduce future __run_timers() latency for first add to empty list
   2549262883c5 timers: Reduce future __run_timers() latency for newly emptied list
   073fac19d3e4 timers: Reduce __run_timers() latency for empty list
   25ca11173e64 timers: Track total number of timers in list
   277a4ae36580 fs/aio: simple simple work
   7b2ebc4e590b lockdep: selftest: fix warnings due to missing PREEMPT_RT conditionals
   9afc01954298 thermal: Defer thermal wakups to threads
   84d35d05b236 locking: ww_mutex: fix ww_mutex vs self-deadlock
   f0c8e4837a51 Revert "rwsem-rt: Do not allow readers to nest"
   df0d51ecf13f sunrpc: make svc_xprt_do_enqueue() use get_cpu_light()
   f069e339ca02 work-simple: Simple work queue implemenation
   0d9e6cbead39 scheduling while atomic in cgroup code
   8405cdab8c2c sas-ata/isci: dont't disable interrupts in qc_issue handler
   dfb7e1ab2427 mips: rt: Replace pagefault_* to raw version
   ddbe4584a13b ARM: cmpxchg: define __HAVE_ARCH_CMPXCHG for armv6 and later
   607f2a27c2ee arm/futex: disable preemption during futex_atomic_cmpxchg_inatomic()
   58de8f60159f ARM: enable irq in translation/section permission fault handlers
   62d90b45607c x86: UV: raw_spinlock conversion
   e8d164191f65 rtmutex: enable deadlock detection in ww_mutex_lock functions
   9612daf936db rt,locking: fix __ww_mutex_lock_interruptible() lockdep annotation
   47915a120d41 rtmutex.c: Fix incorrect waiter check
   a6a68d53df5f locking/rt-mutex: avoid a NULL pointer dereference on deadlock
   fb2c256f8a91 futex: Simplify futex_lock_pi_atomic() and make it more robust
   7e59d4d5900e futex: Split out the first waiter attachment from lookup_pi_state()
   45ccc2e3f25f futex: Split out the waiter check from lookup_pi_state()
   c5133997a345 futex: Use futex_top_waiter() in lookup_pi_state()
   4726c8b47964 futex: Make unlock_pi more robust
   b55c2c7782ee rtmutex: Avoid pointless requeueing in the deadlock detection chain walk
   ff7cfbb757d4 rtmutex: Cleanup deadlock detector debug logic
   e80ba665fa71 rtmutex: Confine deadlock logic to futex
   7a9e7c37ccf4 rtmutex: Simplify remove_waiter()
   d664c14c1db3 rtmutex: Document pi chain walk
   64bcb809c720 rtmutex: Clarify the boost/deboost part
   02323ee362c4 rtmutex: No need to keep task ref for lock owner check
   063983fb0497 rtmutex: Simplify and document try_to_take_rtmutex()
   f87319b715f1 rtmutex: Simplify rtmutex_slowtrylock()
   de9723ae23f9 gpio: omap: use raw locks for locking
   705ad635f56a rt: bump localversion from 22 to 31
   22b5a5cda73a mm/page_alloc: fixup warning from stable merges to -rt

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

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
index 4b602b1b03f6..23e1688daeda 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb
@@ -3,9 +3,9 @@ KBRANCH_qemuppc ?= "standard/preempt-rt/qemuppc"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-SRCREV_machine ?= "3fb54cf8f4c3254f628e6c4720fe3c731a9de0b2"
-SRCREV_machine_qemuppc ?= "ab935c000435b6f5af42543f8e2300e473995d5a"
-SRCREV_meta ?= "162dfe3bb092c1a792e5ed224fe09672e9814b24"
+SRCREV_machine ?= "91dc6afcecd47c08e7e13e674d8d7e9dcede5aca"
+SRCREV_machine_qemuppc ?= "2655b44cfe839f6f9ba15b061e1b4d386d5821f6"
+SRCREV_meta ?= "46df2668fa657162d11f96a6f1af138c562a03aa"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},meta;name=machine,meta"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
index afcc4dd6206c..1d999650611c 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb
@@ -9,8 +9,8 @@ LINUX_VERSION ?= "3.14.36"
 KMETA = "meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "4434aa71ff7043c570f9eae493df1ccadbda9b85"
-SRCREV_meta ?= "162dfe3bb092c1a792e5ed224fe09672e9814b24"
+SRCREV_machine ?= "2a2be8720802fae73fbdf1da37f61d7843332ba3"
+SRCREV_meta ?= "46df2668fa657162d11f96a6f1af138c562a03aa"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.14.bb b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
index b71aea2b18e9..fa433b61c821 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.14.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.14.bb
@@ -11,15 +11,15 @@ KBRANCH_qemux86  ?= "standard/common-pc/base"
 KBRANCH_qemux86-64 ?= "standard/common-pc-64/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "d1cea997ae512ee325600a247d75027e65655e0a"
-SRCREV_machine_qemuarm64 ?= "4434aa71ff7043c570f9eae493df1ccadbda9b85"
-SRCREV_machine_qemumips ?= "c37155f99472e7dc9f94b3bda72c73a3f718fdbf"
-SRCREV_machine_qemuppc ?= "521b9fd001dc25a446d39f349cdfb7f9f5697d05"
-SRCREV_machine_qemux86 ?= "f7cbba6012312f5bf9b7279bafa8bb09d18b547d"
-SRCREV_machine_qemux86-64 ?= "4434aa71ff7043c570f9eae493df1ccadbda9b85"
-SRCREV_machine_qemumips64 ?= "a777f11a26f075b71becb47b5133252c5d8fafff"
-SRCREV_machine ?= "4434aa71ff7043c570f9eae493df1ccadbda9b85"
-SRCREV_meta ?= "162dfe3bb092c1a792e5ed224fe09672e9814b24"
+SRCREV_machine_qemuarm ?= "90f1033d72d422b4e4a8125f68cd1623d6788870"
+SRCREV_machine_qemuarm64 ?= "2a2be8720802fae73fbdf1da37f61d7843332ba3"
+SRCREV_machine_qemumips ?= "bc927927f774c9d12f6c4689dbfba9f5578d0b62"
+SRCREV_machine_qemuppc ?= "e4dfdbf1a059e0edb1be677973f8e2c73e012c8a"
+SRCREV_machine_qemux86 ?= "594bfbce3133d75d9aa569883bdeaed15eeadc8f"
+SRCREV_machine_qemux86-64 ?= "2a2be8720802fae73fbdf1da37f61d7843332ba3"
+SRCREV_machine_qemumips64 ?= "ea8b5406c6ec027d0475146ac84f24eb34196b78"
+SRCREV_machine ?= "2a2be8720802fae73fbdf1da37f61d7843332ba3"
+SRCREV_meta ?= "46df2668fa657162d11f96a6f1af138c562a03aa"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.14.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
 
-- 
2.1.0

[PATCH 2/5] linux-yocto: add core bluetooth support to qemux86* and common-pc*

[Bruce Ashfield]

Updating the configuration for the common x86 platforms to always
include core bluetooth support.

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

diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb
index 15fc536e0a41..1f91471dd622 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb
@@ -10,7 +10,7 @@ KMETA = "meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "d5d30ba4d20e65c15df624ffce7a5cd38150348b"
-SRCREV_meta ?= "1b28e65444c0da26c347eba6272984547ab4983b"
+SRCREV_meta ?= "7215fe431391a322c7e39f410e7b8f2a2b507892"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.19.bb b/meta/recipes-kernel/linux/linux-yocto_3.19.bb
index e47e22b39695..6ddbe8c59336 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.19.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= "d5d30ba4d20e65c15df624ffce7a5cd38150348b"
 SRCREV_machine_qemux86-64 ?= "d5d30ba4d20e65c15df624ffce7a5cd38150348b"
 SRCREV_machine_qemumips64 ?= "f631de1c3df29a85a4b882acf19682fe05eec0f3"
 SRCREV_machine ?= "d5d30ba4d20e65c15df624ffce7a5cd38150348b"
-SRCREV_meta ?= "1b28e65444c0da26c347eba6272984547ab4983b"
+SRCREV_meta ?= "7215fe431391a322c7e39f410e7b8f2a2b507892"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.19.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
 
-- 
2.1.0

[PATCH 3/5] linux-yocto/3.19: Braswell support and bug fixes

[Bruce Ashfield]

Updating to include the following commits:

   a4d0c407cced dmaengine: dw: don't handle interrupt when dmaengine is not used
   e92b2ce791b2 dmaengine: dw: define DW_DMA_MAX_NR_MASTERS
   931304a6567e dmaengine: dw: provide DMA capabilities
   468bad4f7a6f dmaengine: dw: Split device_control
   b4afd7710db7 i2c: i801: Use managed pcim_* PCI device initialization and reservation
   d81a8a11ecba i2c: i801: Remove pci_enable_device() call from i801_resume()
   40e18604e70c i2c: i801: Use managed devm_* memory and irq allocation
   b54f65dbe57b i2c: i801: Remove i801_driver forward declaration
   e95740d4d079 i2c: i801: Don't break user-visible strings
   423e98721e04 ACPI: Introduce has_acpi_companion()
   291f620dc052 i2c: designware: Suppress error message if platform_get_irq() < 0
   cf5ff51a8e3f i2c: designware-pci: no need to provide clk_khz
   4f583ce420d3 i2c: designware-pci: remove Moorestown support
   e000c549c9d8 i2c: designware: Add Intel Baytrail PMIC I2C bus support
   7ffbd9ca19a7 i2c: designware: fixup return handling of wait_for_completion_timeout
   5758d5a1df32 i2c: designware: Do not calculate SCL timing parameters needlessly
   2f58fcae92db i2c: designware: Add i2c bus locking support
   84a73e51e900 i2c: designware: use {readl|writel}_relaxed instead of readl/writel
   f672bb8424e6 serial: 8250_dw: Fix get_mctrl behaviour
   91bd64585489 serial: 8250: add support for ACPI-probed serial port for X-Gene platform
   1190cba71f09 serial:8250:8250_pci: delete unneeded quirk entries
   6405a4b71451 serial:8250:8250_pci: fix redundant entry report for WCH_CH352_2S
   0a1a31bbbc19 serial: 8250_pci: remove one useless explicit type conversion
   4edc52a55f82 intel_idle: Add support for the Airmont Core in the Cherrytrail and Braswell SOCs
   934f85e8bfdb x86/irq, ACPI: Implement ACPI driver to support IOAPIC hotplug
   c6a3440252a8 ACPI / LPSS: check the result of ioremap()
   6aacc0c931b7 pinctrl: update direction_output function of cherryview driver
   cb4a43a2177d pinctrl: cherryview: Configure HiZ pins to be input when requested as GPIOs
   0df22c007ce1 pinctrl: intel: drop owner assignment from platform_drivers
   07b16f04700b pinctrl: cherryview: Save and restore pin configs over system sleep
   e8e5cfffa231 pinctrl: baytrail: Save pin context over system sleep
   04cb3cc0ff21 pinctrl: baytrail: Rework interrupt handling
   4cac25d2574d pinctrl: baytrail: Clear interrupt triggering from pins that are in GPIO mode
   eacab9ab234a pinctrl: baytrail: Relax GPIO request rules

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

diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb
index 1f91471dd622..691637563986 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb
@@ -9,7 +9,7 @@ LINUX_VERSION ?= "3.19.5"
 KMETA = "meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "d5d30ba4d20e65c15df624ffce7a5cd38150348b"
+SRCREV_machine ?= "a4d0c407cced779d1d84ea6284e48ea7366e9544"
 SRCREV_meta ?= "7215fe431391a322c7e39f410e7b8f2a2b507892"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_3.19.bb b/meta/recipes-kernel/linux/linux-yocto_3.19.bb
index 6ddbe8c59336..ccba54424b10 100644
--- a/meta/recipes-kernel/linux/linux-yocto_3.19.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_3.19.bb
@@ -11,14 +11,14 @@ KBRANCH_qemux86  ?= "standard/common-pc"
 KBRANCH_qemux86-64 ?= "standard/common-pc-64/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "4f9b327ff33521c08ed279891e2a2099b5504d0e"
-SRCREV_machine_qemuarm64 ?= "d5d30ba4d20e65c15df624ffce7a5cd38150348b"
-SRCREV_machine_qemumips ?= "03b975caa49e6e1693d6fe5fec8f316e0481ead5"
-SRCREV_machine_qemuppc ?= "9a3edc9c341e6f57423f2b4b218b83a84fc2726d"
-SRCREV_machine_qemux86 ?= "d5d30ba4d20e65c15df624ffce7a5cd38150348b"
-SRCREV_machine_qemux86-64 ?= "d5d30ba4d20e65c15df624ffce7a5cd38150348b"
-SRCREV_machine_qemumips64 ?= "f631de1c3df29a85a4b882acf19682fe05eec0f3"
-SRCREV_machine ?= "d5d30ba4d20e65c15df624ffce7a5cd38150348b"
+SRCREV_machine_qemuarm ?= "84448662cec5620ea32b3c222dca69e7d3d7ba7c"
+SRCREV_machine_qemuarm64 ?= "a4d0c407cced779d1d84ea6284e48ea7366e9544"
+SRCREV_machine_qemumips ?= "14c37927fe0d6e0ecd7e8c57d7fbd0828361ef2e"
+SRCREV_machine_qemuppc ?= "deaab2afa62b7e903dbcea7b6c5ab9a58c3cf4a3"
+SRCREV_machine_qemux86 ?= "a4d0c407cced779d1d84ea6284e48ea7366e9544"
+SRCREV_machine_qemux86-64 ?= "a4d0c407cced779d1d84ea6284e48ea7366e9544"
+SRCREV_machine_qemumips64 ?= "6f8e66bf8d7a215f11f8fb168a59fa1ef1b0ff87"
+SRCREV_machine ?= "a4d0c407cced779d1d84ea6284e48ea7366e9544"
 SRCREV_meta ?= "7215fe431391a322c7e39f410e7b8f2a2b507892"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.19.git;bareclone=1;branch=${KBRANCH},${KMETA};name=machine,meta"
-- 
2.1.0

[PATCH 4/5] perf: fix build (and feature tests) for 4.1-rcX

[Bruce Ashfield]

The way that perf detects features has changed/moved via commit e6c76d620
[perf build: Move feature checks code under tools/build].

This code movement resulted in the definition of CC being dropped, and
in turn the passing of --sysroot not part of the build.

This results in feature tests failing with errors such as:

  In file included from test-pthread-attr-setaffinity-np.c:1:0:
  sysroots/x86_64-linux/usr/lib/x86_64-poky-linux/gcc/x86_64-poky-linux/4.9.2/include/stdint.h:9:26:
  fatal error: stdint.h: No such file or directory
  # include_next <stdint.h>
                          ^
  compilation terminated.

While the fix is going upstream, we can modify the perf recipe to add
the definition of CC into the Makefile, and we'll continue to work on
patched and unpatched kernels.

Upstream-status: Pending

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/perf/perf.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 420fe6b57aba..eb273740ee10 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -150,6 +150,9 @@ do_configure_prepend () {
     if [ -e "${S}/tools/perf/config/feature-checks/Makefile" ]; then
         sed -i 's,CC := $(CROSS_COMPILE)gcc -MD,CC += -MD,' ${S}/tools/perf/config/feature-checks/Makefile
     fi
+    if [ -e "${S}/tools/build/Makefile.feature" ]; then
+        sed -i 's,CFLAGS=,CC="\$(CC)" CFLAGS=,' ${S}/tools/build/Makefile.feature
+    fi
 
     # 3.17-rc1+ has a include issue for arm/powerpc. Temporarily sed in the appropriate include
     if [ -e "${S}/tools/perf/arch/$ARCH/util/skip-callchain-idx.c" ]; then
-- 
2.1.0

[PATCH 5/5] linux-yocto-dev: introduce 4.1-rc development kernel

[Bruce Ashfield]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index ba88fd7dc337..588a89f6411b 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -35,7 +35,7 @@ SRC_URI = "git://git.yoctoproject.org/linux-yocto-dev.git;bareclone=1;branch=${K
 SRCREV_machine ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
 SRCREV_meta ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", d)}'
 
-LINUX_VERSION ?= "3.19+"
+LINUX_VERSION ?= "4.1-rc+"
 LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
2.1.0

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Richard Purdie]

On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
> Here is the latest consolidated pull request for the supported linux-yocto
> kernels.
> 
>  - We have a refresh of the 3.14-rt support
>  - bluetooh configuration changes for common-pc/qemux86
>  - braswell BSP features and fixes
>  - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
> 
> I've built and booted these on my local machines and qemu, and
> everything was sane.
> 
> The -dev kernel obviously isn't something for deployment yet, but
> it builds, and forms the base for follow up config changes, features
> and development work. I built and booted core-image-kernel dev with
> the 4.1 changes in place.

The autobuilder showed up this for an x32 build :/.

https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/282/steps/BuildImages/logs/stdio

Cheers,

Richard

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Bruce Ashfield]

On 2015-05-01 6:59 PM, Richard Purdie wrote:
> On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
>> Here is the latest consolidated pull request for the supported linux-yocto
>> kernels.
>>
>>   - We have a refresh of the 3.14-rt support
>>   - bluetooh configuration changes for common-pc/qemux86
>>   - braswell BSP features and fixes
>>   - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
>>
>> I've built and booted these on my local machines and qemu, and
>> everything was sane.
>>
>> The -dev kernel obviously isn't something for deployment yet, but
>> it builds, and forms the base for follow up config changes, features
>> and development work. I built and booted core-image-kernel dev with
>> the 4.1 changes in place.
>
> The autobuilder showed up this for an x32 build :/.

Can one of the intel folks have a look at this ? I won't be able to get
to it until Tuesday at the earliest.

Bruce

>
> https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/282/steps/BuildImages/logs/stdio
>
> Cheers,
>
> Richard
>

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Martin Jansa]

On Fri, May 01, 2015 at 07:30:24PM -0400, Bruce Ashfield wrote:
> On 2015-05-01 6:59 PM, Richard Purdie wrote:
> > On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
> >> Here is the latest consolidated pull request for the supported linux-yocto
> >> kernels.
> >>
> >>   - We have a refresh of the 3.14-rt support
> >>   - bluetooh configuration changes for common-pc/qemux86
> >>   - braswell BSP features and fixes
> >>   - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
> >> I've built and booted these on my local machines and qemu, and
> >> everything was sane.

Does it fix the issue I've reported few days ago?
http://lists.openembedded.org/pipermail/openembedded-core/2015-April/104344.html

> >> The -dev kernel obviously isn't something for deployment yet, but
> >> it builds, and forms the base for follow up config changes, features
> >> and development work. I built and booted core-image-kernel dev with
> >> the 4.1 changes in place.
> >
> > The autobuilder showed up this for an x32 build :/.
> 
> Can one of the intel folks have a look at this ? I won't be able to get
> to it until Tuesday at the earliest.
> 
> Bruce
> 
> >
> > https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/282/steps/BuildImages/logs/stdio
> >
> > Cheers,
> >
> > Richard
> >
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Bruce Ashfield]

On 2015-05-02 4:13 AM, Martin Jansa wrote:
> On Fri, May 01, 2015 at 07:30:24PM -0400, Bruce Ashfield wrote:
>> On 2015-05-01 6:59 PM, Richard Purdie wrote:
>>> On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
>>>> Here is the latest consolidated pull request for the supported linux-yocto
>>>> kernels.
>>>>
>>>>    - We have a refresh of the 3.14-rt support
>>>>    - bluetooh configuration changes for common-pc/qemux86
>>>>    - braswell BSP features and fixes
>>>>    - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
>>>> I've built and booted these on my local machines and qemu, and
>>>> everything was sane.
>
> Does it fix the issue I've reported few days ago?
> http://lists.openembedded.org/pipermail/openembedded-core/2015-April/104344.html

Nope. But one config warning is far down on the list when I'm
trying to introduce new -stable's and an entire -dev kernel.

I didn't forget about it, it'll just get done in priority order.

Bruce

>
>>>> The -dev kernel obviously isn't something for deployment yet, but
>>>> it builds, and forms the base for follow up config changes, features
>>>> and development work. I built and booted core-image-kernel dev with
>>>> the 4.1 changes in place.
>>>
>>> The autobuilder showed up this for an x32 build :/.
>>
>> Can one of the intel folks have a look at this ? I won't be able to get
>> to it until Tuesday at the earliest.
>>
>> Bruce
>>
>>>
>>> https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/282/steps/BuildImages/logs/stdio
>>>
>>> Cheers,
>>>
>>> Richard
>>>
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Martin Jansa]

On Sat, May 02, 2015 at 10:50:53PM -0400, Bruce Ashfield wrote:
> On 2015-05-02 4:13 AM, Martin Jansa wrote:
> > On Fri, May 01, 2015 at 07:30:24PM -0400, Bruce Ashfield wrote:
> >> On 2015-05-01 6:59 PM, Richard Purdie wrote:
> >>> On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
> >>>> Here is the latest consolidated pull request for the supported linux-yocto
> >>>> kernels.
> >>>>
> >>>>    - We have a refresh of the 3.14-rt support
> >>>>    - bluetooh configuration changes for common-pc/qemux86
> >>>>    - braswell BSP features and fixes
> >>>>    - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
> >>>> I've built and booted these on my local machines and qemu, and
> >>>> everything was sane.
> >
> > Does it fix the issue I've reported few days ago?
> > http://lists.openembedded.org/pipermail/openembedded-core/2015-April/104344.html
> 
> Nope. But one config warning is far down on the list when I'm
> trying to introduce new -stable's and an entire -dev kernel.
> 
> I didn't forget about it, it'll just get done in priority order.

OK, now it fails completely in default qemux86 builds:

ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/3.19.5+gitAUTOINC+7215fe4313_d5d30ba4d2-r0/temp/log.do_kernel_configme.1159)
ERROR: Logfile of failure stored in: /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/3.19.5+gitAUTOINC+7215fe4313_d5d30ba4d2-r0/temp/log.do_kernel_configme.1159
Log data follows:
| DEBUG: Executing shell function do_kernel_configme
| NOTE: kernel configme
| [INFO] Configuring target/machine combo: "standard/qemux86"
| [INFO] collecting configs in .meta/meta-series
| [ERROR] frag /home/jenkins/oe/world/shr-core/tmp-glibc/work-shared/qemux86/kernel-source/.meta/cfg/kernel-cache/bsp/common-pc/common-pc-drivers-32.cfg does not exist
| Error running the meta series for collecting config data
| config of "standard/qemux86" failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/3.19.5+gitAUTOINC+7215fe4313_d5d30ba4d2-r0/temp/log.do_kernel_configme.1159)
NOTE: recipe linux-yocto-3.19.5+gitAUTOINC+7215fe4313_d5d30ba4d2-r0: task do_kernel_configme: Failed
ERROR: Task 30162 (/home/jenkins/oe/world/shr-core/openembedded-core/meta/recipes-kernel/linux/linux-yocto_3.19.bb, do_kernel_configme) failed with exit code '1'

http://errors.yoctoproject.org/Errors/Details/10481/

> >>>> The -dev kernel obviously isn't something for deployment yet, but
> >>>> it builds, and forms the base for follow up config changes, features
> >>>> and development work. I built and booted core-image-kernel dev with
> >>>> the 4.1 changes in place.
> >>>
> >>> The autobuilder showed up this for an x32 build :/.
> >>
> >> Can one of the intel folks have a look at this ? I won't be able to get
> >> to it until Tuesday at the earliest.
> >>
> >> Bruce
> >>
> >>>
> >>> https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/282/steps/BuildImages/logs/stdio
> >>>
> >>> Cheers,
> >>>
> >>> Richard
> >>>
> >>
> >> --
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> 

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Bruce Ashfield]

On 2015-05-06 10:42 AM, Martin Jansa wrote:
> On Sat, May 02, 2015 at 10:50:53PM -0400, Bruce Ashfield wrote:
>> On 2015-05-02 4:13 AM, Martin Jansa wrote:
>>> On Fri, May 01, 2015 at 07:30:24PM -0400, Bruce Ashfield wrote:
>>>> On 2015-05-01 6:59 PM, Richard Purdie wrote:
>>>>> On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
>>>>>> Here is the latest consolidated pull request for the supported linux-yocto
>>>>>> kernels.
>>>>>>
>>>>>>     - We have a refresh of the 3.14-rt support
>>>>>>     - bluetooh configuration changes for common-pc/qemux86
>>>>>>     - braswell BSP features and fixes
>>>>>>     - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
>>>>>> I've built and booted these on my local machines and qemu, and
>>>>>> everything was sane.
>>>
>>> Does it fix the issue I've reported few days ago?
>>> http://lists.openembedded.org/pipermail/openembedded-core/2015-April/104344.html
>>
>> Nope. But one config warning is far down on the list when I'm
>> trying to introduce new -stable's and an entire -dev kernel.
>>
>> I didn't forget about it, it'll just get done in priority order.
>
> OK, now it fails completely in default qemux86 builds:
>

At this point, all I can say is file a bug. My builds of the same
board work, and the autobuilder show up green.

That screams race condition, so I'll look into it from that angle.

Bruce

> ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/3.19.5+gitAUTOINC+7215fe4313_d5d30ba4d2-r0/temp/log.do_kernel_configme.1159)
> ERROR: Logfile of failure stored in: /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/3.19.5+gitAUTOINC+7215fe4313_d5d30ba4d2-r0/temp/log.do_kernel_configme.1159
> Log data follows:
> | DEBUG: Executing shell function do_kernel_configme
> | NOTE: kernel configme
> | [INFO] Configuring target/machine combo: "standard/qemux86"
> | [INFO] collecting configs in .meta/meta-series
> | [ERROR] frag /home/jenkins/oe/world/shr-core/tmp-glibc/work-shared/qemux86/kernel-source/.meta/cfg/kernel-cache/bsp/common-pc/common-pc-drivers-32.cfg does not exist
> | Error running the meta series for collecting config data
> | config of "standard/qemux86" failed
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/3.19.5+gitAUTOINC+7215fe4313_d5d30ba4d2-r0/temp/log.do_kernel_configme.1159)
> NOTE: recipe linux-yocto-3.19.5+gitAUTOINC+7215fe4313_d5d30ba4d2-r0: task do_kernel_configme: Failed
> ERROR: Task 30162 (/home/jenkins/oe/world/shr-core/openembedded-core/meta/recipes-kernel/linux/linux-yocto_3.19.bb, do_kernel_configme) failed with exit code '1'
>
> http://errors.yoctoproject.org/Errors/Details/10481/
>
>>>>>> The -dev kernel obviously isn't something for deployment yet, but
>>>>>> it builds, and forms the base for follow up config changes, features
>>>>>> and development work. I built and booted core-image-kernel dev with
>>>>>> the 4.1 changes in place.
>>>>>
>>>>> The autobuilder showed up this for an x32 build :/.
>>>>
>>>> Can one of the intel folks have a look at this ? I won't be able to get
>>>> to it until Tuesday at the earliest.
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/282/steps/BuildImages/logs/stdio
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Richard
>>>>>
>>>>
>>>> --
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>
>

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Martin Jansa]

On Wed, May 06, 2015 at 10:58:36AM -0400, Bruce Ashfield wrote:
> On 2015-05-06 10:42 AM, Martin Jansa wrote:
> > On Sat, May 02, 2015 at 10:50:53PM -0400, Bruce Ashfield wrote:
> >> On 2015-05-02 4:13 AM, Martin Jansa wrote:
> >>> On Fri, May 01, 2015 at 07:30:24PM -0400, Bruce Ashfield wrote:
> >>>> On 2015-05-01 6:59 PM, Richard Purdie wrote:
> >>>>> On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
> >>>>>> Here is the latest consolidated pull request for the supported linux-yocto
> >>>>>> kernels.
> >>>>>>
> >>>>>>     - We have a refresh of the 3.14-rt support
> >>>>>>     - bluetooh configuration changes for common-pc/qemux86
> >>>>>>     - braswell BSP features and fixes
> >>>>>>     - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
> >>>>>> I've built and booted these on my local machines and qemu, and
> >>>>>> everything was sane.
> >>>
> >>> Does it fix the issue I've reported few days ago?
> >>> http://lists.openembedded.org/pipermail/openembedded-core/2015-April/104344.html
> >>
> >> Nope. But one config warning is far down on the list when I'm
> >> trying to introduce new -stable's and an entire -dev kernel.
> >>
> >> I didn't forget about it, it'll just get done in priority order.
> >
> > OK, now it fails completely in default qemux86 builds:
> >
> 
> At this point, all I can say is file a bug. My builds of the same
> board work, and the autobuilder show up green.
> 
> That screams race condition, so I'll look into it from that angle.

I'm considering providing simple old-style recipes for vanilla kernels
and using them in my jenkins builds instead linux-yocto, because kernel
shouldn't block testing other recipes from meta-oe and other layers as
often as linux-yocto does.

> > ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/3.19.5+gitAUTOINC+7215fe4313_d5d30ba4d2-r0/temp/log.do_kernel_configme.1159)
> > ERROR: Logfile of failure stored in: /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/3.19.5+gitAUTOINC+7215fe4313_d5d30ba4d2-r0/temp/log.do_kernel_configme.1159
> > Log data follows:
> > | DEBUG: Executing shell function do_kernel_configme
> > | NOTE: kernel configme
> > | [INFO] Configuring target/machine combo: "standard/qemux86"
> > | [INFO] collecting configs in .meta/meta-series
> > | [ERROR] frag /home/jenkins/oe/world/shr-core/tmp-glibc/work-shared/qemux86/kernel-source/.meta/cfg/kernel-cache/bsp/common-pc/common-pc-drivers-32.cfg does not exist
> > | Error running the meta series for collecting config data
> > | config of "standard/qemux86" failed
> > | WARNING: exit code 1 from a shell command.
> > | ERROR: Function failed: do_kernel_configme (log file is located at /home/jenkins/oe/world/shr-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/3.19.5+gitAUTOINC+7215fe4313_d5d30ba4d2-r0/temp/log.do_kernel_configme.1159)
> > NOTE: recipe linux-yocto-3.19.5+gitAUTOINC+7215fe4313_d5d30ba4d2-r0: task do_kernel_configme: Failed
> > ERROR: Task 30162 (/home/jenkins/oe/world/shr-core/openembedded-core/meta/recipes-kernel/linux/linux-yocto_3.19.bb, do_kernel_configme) failed with exit code '1'
> >
> > http://errors.yoctoproject.org/Errors/Details/10481/
> >
> >>>>>> The -dev kernel obviously isn't something for deployment yet, but
> >>>>>> it builds, and forms the base for follow up config changes, features
> >>>>>> and development work. I built and booted core-image-kernel dev with
> >>>>>> the 4.1 changes in place.
> >>>>>
> >>>>> The autobuilder showed up this for an x32 build :/.
> >>>>
> >>>> Can one of the intel folks have a look at this ? I won't be able to get
> >>>> to it until Tuesday at the earliest.
> >>>>
> >>>> Bruce
> >>>>
> >>>>>
> >>>>> https://autobuilder.yoctoproject.org/main/builders/nightly-x32/builds/282/steps/BuildImages/logs/stdio
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Richard
> >>>>>
> >>>>
> >>>> --
> >>>> _______________________________________________
> >>>> Openembedded-core mailing list
> >>>> Openembedded-core@lists.openembedded.org
> >>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>>
> >>
> >
> 

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Richard Purdie]

On Wed, 2015-05-06 at 17:33 +0200, Martin Jansa wrote:
> On Wed, May 06, 2015 at 10:58:36AM -0400, Bruce Ashfield wrote:
> > On 2015-05-06 10:42 AM, Martin Jansa wrote:
> > At this point, all I can say is file a bug. My builds of the same
> > board work, and the autobuilder show up green.
> > 
> > That screams race condition, so I'll look into it from that angle.
> 
> I'm considering providing simple old-style recipes for vanilla kernels
> and using them in my jenkins builds instead linux-yocto, because kernel
> shouldn't block testing other recipes from meta-oe and other layers as
> often as linux-yocto does.

I wasn't aware of linux-yocto breaking that often?

I am aware that:

* we have a race issue with shared_work which we're trying to resolve
  and its proving tricky to find a patch which doesn't break builds

* we have the newly reported issue in this thread. FWIW the builders 
  I've seen are all green

* there are some warnings in the build which need addressing

but on the most part I thought we'd caught the serious kernel failures
in advance of changes hitting master. Are you using master-next or
master? 

Its its -next, I can understand the problems more as that has been
unstable recently but then by its nature, it can be. We are rooting out
problems before master afaict though?

Cheers,

Richard
 

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Martin Jansa]

On Wed, May 06, 2015 at 04:44:46PM +0100, Richard Purdie wrote:
> On Wed, 2015-05-06 at 17:33 +0200, Martin Jansa wrote:
> > On Wed, May 06, 2015 at 10:58:36AM -0400, Bruce Ashfield wrote:
> > > On 2015-05-06 10:42 AM, Martin Jansa wrote:
> > > At this point, all I can say is file a bug. My builds of the same
> > > board work, and the autobuilder show up green.
> > > 
> > > That screams race condition, so I'll look into it from that angle.
> > 
> > I'm considering providing simple old-style recipes for vanilla kernels
> > and using them in my jenkins builds instead linux-yocto, because kernel
> > shouldn't block testing other recipes from meta-oe and other layers as
> > often as linux-yocto does.
> 
> I wasn't aware of linux-yocto breaking that often?

Someone can query http://errors.yoctoproject.org/ database to see how
often (or if it's just me and my builds), unfortunately the full-text
search for "linux-yocto" doesn't provide good overview of issues,
because it shows 350 errors and not all are from linux-yocto recipe.

http://www.openembedded.org/wiki/Bitbake_World_Status* pages and status
on e-mail also aren't very accurate because I submit only reports from
relatively success full builds (so I usually skip the builds with failed
kernel, unless it's failing like that for long time).

> I am aware that:
> 
> * we have a race issue with shared_work which we're trying to resolve
>   and its proving tricky to find a patch which doesn't break builds
> 
> * we have the newly reported issue in this thread. FWIW the builders 
>   I've seen are all green
> 
> * there are some warnings in the build which need addressing
> 
> but on the most part I thought we'd caught the serious kernel failures
> in advance of changes hitting master. Are you using master-next or
> master? 

I've used master-next week or two ago (mostly to test bluez4 and python3
changes) and soon after that dropped all linux-yocto related changes
from it assuming that it's indeed cause for the issues I'm seeing, but
it's not and it's still failing with master as well (and my
jenkins/world builds are just small portion of my builds executed
elsewhere where I see similar issues).

> Its its -next, I can understand the problems more as that has been
> unstable recently but then by its nature, it can be. We are rooting out
> problems before master afaict though?
> 
> Cheers,
> 
> Richard

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Bruce Ashfield]

On 2015-05-06 12:07 PM, Martin Jansa wrote:
> On Wed, May 06, 2015 at 04:44:46PM +0100, Richard Purdie wrote:
>> On Wed, 2015-05-06 at 17:33 +0200, Martin Jansa wrote:
>>> On Wed, May 06, 2015 at 10:58:36AM -0400, Bruce Ashfield wrote:
>>>> On 2015-05-06 10:42 AM, Martin Jansa wrote:
>>>> At this point, all I can say is file a bug. My builds of the same
>>>> board work, and the autobuilder show up green.
>>>>
>>>> That screams race condition, so I'll look into it from that angle.
>>>
>>> I'm considering providing simple old-style recipes for vanilla kernels
>>> and using them in my jenkins builds instead linux-yocto, because kernel
>>> shouldn't block testing other recipes from meta-oe and other layers as
>>> often as linux-yocto does.
>>
>> I wasn't aware of linux-yocto breaking that often?
>
> Someone can query http://errors.yoctoproject.org/ database to see how
> often (or if it's just me and my builds), unfortunately the full-text
> search for "linux-yocto" doesn't provide good overview of issues,
> because it shows 350 errors and not all are from linux-yocto recipe.
>
> http://www.openembedded.org/wiki/Bitbake_World_Status* pages and status
> on e-mail also aren't very accurate because I submit only reports from
> relatively success full builds (so I usually skip the builds with failed
> kernel, unless it's failing like that for long time).
>
>> I am aware that:
>>
>> * we have a race issue with shared_work which we're trying to resolve
>>    and its proving tricky to find a patch which doesn't break builds
>>
>> * we have the newly reported issue in this thread. FWIW the builders
>>    I've seen are all green
>>
>> * there are some warnings in the build which need addressing
>>
>> but on the most part I thought we'd caught the serious kernel failures
>> in advance of changes hitting master. Are you using master-next or
>> master?
>
> I've used master-next week or two ago (mostly to test bluez4 and python3
> changes) and soon after that dropped all linux-yocto related changes
> from it assuming that it's indeed cause for the issues I'm seeing, but
> it's not and it's still failing with master as well (and my
> jenkins/world builds are just small portion of my builds executed
> elsewhere where I see similar issues).

Richard: How can we sort out the differences between the build
environment that Martin uses versus what the autobuilder is showing?

There's nothing particularly complex happening during that build,
it's a checkout and generation of a config.

I'm unable to reproduce any of the failures, and neither is the
autobuilder.

I've stared at the code and can't see what could cause any of this.

That being said, I think I have a solution to what Martin is reporting
here, where I've changed the way the meta data is maintained and
build.

It will be ready in a week or so, so I'd be interested in us holding
on anything drastic until we can try that out.

Bruce

>
>> Its its -next, I can understand the problems more as that has been
>> unstable recently but then by its nature, it can be. We are rooting out
>> problems before master afaict though?
>>
>> Cheers,
>>
>> Richard
>

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Richard Purdie]

On Wed, 2015-05-06 at 13:46 -0400, Bruce Ashfield wrote:
> On 2015-05-06 12:07 PM, Martin Jansa wrote:
> > I've used master-next week or two ago (mostly to test bluez4 and python3
> > changes) and soon after that dropped all linux-yocto related changes
> > from it assuming that it's indeed cause for the issues I'm seeing, but
> > it's not and it's still failing with master as well (and my
> > jenkins/world builds are just small portion of my builds executed
> > elsewhere where I see similar issues).
> 
> Richard: How can we sort out the differences between the build
> environment that Martin uses versus what the autobuilder is showing?
> 
> There's nothing particularly complex happening during that build,
> it's a checkout and generation of a config.
> 
> I'm unable to reproduce any of the failures, and neither is the
> autobuilder.

This is a tough one and I'm struggling a little. We could try looking at
the tmp/stamps/qemux86-poky-linux/linux-yocto/* files (sigdata in
particular) as well as
tmp/work/qemux86-poky-linux/linux-yocto/*/temp/log.task_order

Martin, would you be able to share the above somewhere? I'm hoping this
would give us a clue as to what the difference is between the builds and
allow us to reproduce the problem.

Cheers,

Richard

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Martin Jansa]

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

I use tmpfs in most of my builds, so in most cases when I see the error
from the build, tmpfs is already gone (purged by next build executed on the
same sever).

On Wed, May 6, 2015 at 11:32 PM, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Wed, 2015-05-06 at 13:46 -0400, Bruce Ashfield wrote:
> > On 2015-05-06 12:07 PM, Martin Jansa wrote:
> > > I've used master-next week or two ago (mostly to test bluez4 and
> python3
> > > changes) and soon after that dropped all linux-yocto related changes
> > > from it assuming that it's indeed cause for the issues I'm seeing, but
> > > it's not and it's still failing with master as well (and my
> > > jenkins/world builds are just small portion of my builds executed
> > > elsewhere where I see similar issues).
> >
> > Richard: How can we sort out the differences between the build
> > environment that Martin uses versus what the autobuilder is showing?
> >
> > There's nothing particularly complex happening during that build,
> > it's a checkout and generation of a config.
> >
> > I'm unable to reproduce any of the failures, and neither is the
> > autobuilder.
>
> This is a tough one and I'm struggling a little. We could try looking at
> the tmp/stamps/qemux86-poky-linux/linux-yocto/* files (sigdata in
> particular) as well as
> tmp/work/qemux86-poky-linux/linux-yocto/*/temp/log.task_order
>
> Martin, would you be able to share the above somewhere? I'm hoping this
> would give us a clue as to what the difference is between the builds and
> allow us to reproduce the problem.
>
> Cheers,
>
> Richard
>
>
>

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

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Bruce Ashfield]

On 2015-05-06 06:49 PM, Martin Jansa wrote:
> I use tmpfs in most of my builds, so in most cases when I see the error
> from the build, tmpfs is already gone (purged by next build executed on
> the same sever).

ross just found something like this in one of his local builds .. I'm
pretty sure I see the race.

Fix coming shortly, and then the bigger changes I was mentioning before
as well.

Cheers,

Bruce

>
> On Wed, May 6, 2015 at 11:32 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org
> <mailto:richard.purdie@linuxfoundation.org>> wrote:
>
>     On Wed, 2015-05-06 at 13:46 -0400, Bruce Ashfield wrote:
>     > On 2015-05-06 12:07 PM, Martin Jansa wrote:
>     > > I've used master-next week or two ago (mostly to test bluez4 and python3
>     > > changes) and soon after that dropped all linux-yocto related changes
>     > > from it assuming that it's indeed cause for the issues I'm seeing, but
>     > > it's not and it's still failing with master as well (and my
>     > > jenkins/world builds are just small portion of my builds executed
>     > > elsewhere where I see similar issues).
>     >
>     > Richard: How can we sort out the differences between the build
>     > environment that Martin uses versus what the autobuilder is showing?
>     >
>     > There's nothing particularly complex happening during that build,
>     > it's a checkout and generation of a config.
>     >
>     > I'm unable to reproduce any of the failures, and neither is the
>     > autobuilder.
>
>     This is a tough one and I'm struggling a little. We could try looking at
>     the tmp/stamps/qemux86-poky-linux/linux-yocto/* files (sigdata in
>     particular) as well as
>     tmp/work/qemux86-poky-linux/linux-yocto/*/temp/log.task_order
>
>     Martin, would you be able to share the above somewhere? I'm hoping this
>     would give us a clue as to what the difference is between the builds and
>     allow us to reproduce the problem.
>
>     Cheers,
>
>     Richard
>
>
>

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Khem Raj]

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


> On May 6, 2015, at 8:33 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> 
> I'm considering providing simple old-style recipes for vanilla kernels
> and using them in my jenkins builds instead linux-yocto, because kernel
> shouldn't block testing other recipes from meta-oe and other layers as
> often as linux-yocto does.

just for build sake to avoid full kernel builds, having a dummy kernel recipe should be another alternative


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Richard Purdie]

On Fri, 2015-05-01 at 19:30 -0400, Bruce Ashfield wrote:
> On 2015-05-01 6:59 PM, Richard Purdie wrote:
> > On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
> >> Here is the latest consolidated pull request for the supported linux-yocto
> >> kernels.
> >>
> >>   - We have a refresh of the 3.14-rt support
> >>   - bluetooh configuration changes for common-pc/qemux86
> >>   - braswell BSP features and fixes
> >>   - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
> >>
> >> I've built and booted these on my local machines and qemu, and
> >> everything was sane.
> >>
> >> The -dev kernel obviously isn't something for deployment yet, but
> >> it builds, and forms the base for follow up config changes, features
> >> and development work. I built and booted core-image-kernel dev with
> >> the 4.1 changes in place.
> >
> > The autobuilder showed up this for an x32 build :/.
> 
> Can one of the intel folks have a look at this ? I won't be able to get
> to it until Tuesday at the earliest.

I had a look into this. The issue is that this has been applied:

http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.19/commit/?h=standard/base&id=423e98721e048f6c7b925a75448f6c4ecb2b5b69

but it needs:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ce793486e23e0162a732c605189c8028e0910e86

and the ioapic driver also appears to need:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=ecf5636dcd59cd5508641f995cc4c2bafedbb995
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=62d1141ff34e35de496ba06491c8e854b23b3f3e


which meant I also had to add:

struct resource_win {
	struct resource res;		/* In master (CPU) address space */
	resource_size_t offset;		/* Translation offset for bridge */
};

to drivers/acpi/ioapic.c to make it compile which appears to be related to:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a49170b552423a3e85fc4f0d778c707402ee4863

which depends on a number of patches from around that time which change acpi/resource.c:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/acpi/resource.c

(from 2015/2/3)

At this point I'm out my depth on how you want to fix this but it does
appear related to the Braswell changes.

To be clear qemux86 and qemux86-64 don't build at all with this series.
I'll see if I can just drop the Braswell parts.

Cheers,

Richard

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Bruce Ashfield]

On 2015-05-02 5:00 AM, Richard Purdie wrote:
> On Fri, 2015-05-01 at 19:30 -0400, Bruce Ashfield wrote:
>> On 2015-05-01 6:59 PM, Richard Purdie wrote:
>>> On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
>>>> Here is the latest consolidated pull request for the supported linux-yocto
>>>> kernels.
>>>>
>>>>    - We have a refresh of the 3.14-rt support
>>>>    - bluetooh configuration changes for common-pc/qemux86
>>>>    - braswell BSP features and fixes
>>>>    - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
>>>>
>>>> I've built and booted these on my local machines and qemu, and
>>>> everything was sane.
>>>>
>>>> The -dev kernel obviously isn't something for deployment yet, but
>>>> it builds, and forms the base for follow up config changes, features
>>>> and development work. I built and booted core-image-kernel dev with
>>>> the 4.1 changes in place.
>>>
>>> The autobuilder showed up this for an x32 build :/.
>>
>> Can one of the intel folks have a look at this ? I won't be able to get
>> to it until Tuesday at the earliest.
>
> I had a look into this. The issue is that this has been applied:
>
> http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.19/commit/?h=standard/base&id=423e98721e048f6c7b925a75448f6c4ecb2b5b69
>
> but it needs:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ce793486e23e0162a732c605189c8028e0910e86
>
> and the ioapic driver also appears to need:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=ecf5636dcd59cd5508641f995cc4c2bafedbb995
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=62d1141ff34e35de496ba06491c8e854b23b3f3e
>
>
> which meant I also had to add:
>
> struct resource_win {
> 	struct resource res;		/* In master (CPU) address space */
> 	resource_size_t offset;		/* Translation offset for bridge */
> };
>
> to drivers/acpi/ioapic.c to make it compile which appears to be related to:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a49170b552423a3e85fc4f0d778c707402ee4863
>
> which depends on a number of patches from around that time which change acpi/resource.c:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/acpi/resource.c
>
> (from 2015/2/3)
>
> At this point I'm out my depth on how you want to fix this but it does
> appear related to the Braswell changes.
>
> To be clear qemux86 and qemux86-64 don't build at all with this series.
> I'll see if I can just drop the Braswell parts.

Gah. It figures. That's of course the issue with any set of BSP ports ..
they get tangled up with Greg's series from time to time.

The changes are all additive, so we can't really drop the braswell parts
unless I revert the whole block of changes.

Drop those -stable updates for now, and I'll see if I can carve out some
time tomorrow to get that config building.

Bruce

>
> Cheers,
>
> Richard
>

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Bruce Ashfield]

On 2015-05-02 5:00 AM, Richard Purdie wrote:
> On Fri, 2015-05-01 at 19:30 -0400, Bruce Ashfield wrote:
>> On 2015-05-01 6:59 PM, Richard Purdie wrote:
>>> On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
>>>> Here is the latest consolidated pull request for the supported linux-yocto
>>>> kernels.
>>>>
>>>>    - We have a refresh of the 3.14-rt support
>>>>    - bluetooh configuration changes for common-pc/qemux86
>>>>    - braswell BSP features and fixes
>>>>    - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
>>>>
>>>> I've built and booted these on my local machines and qemu, and
>>>> everything was sane.
>>>>
>>>> The -dev kernel obviously isn't something for deployment yet, but
>>>> it builds, and forms the base for follow up config changes, features
>>>> and development work. I built and booted core-image-kernel dev with
>>>> the 4.1 changes in place.
>>>
>>> The autobuilder showed up this for an x32 build :/.
>>
>> Can one of the intel folks have a look at this ? I won't be able to get
>> to it until Tuesday at the earliest.
>
> I had a look into this. The issue is that this has been applied:
>
> http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.19/commit/?h=standard/base&id=423e98721e048f6c7b925a75448f6c4ecb2b5b69
>
> but it needs:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ce793486e23e0162a732c605189c8028e0910e86
>
> and the ioapic driver also appears to need:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=ecf5636dcd59cd5508641f995cc4c2bafedbb995
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=62d1141ff34e35de496ba06491c8e854b23b3f3e
>
>
> which meant I also had to add:
>
> struct resource_win {
> 	struct resource res;		/* In master (CPU) address space */
> 	resource_size_t offset;		/* Translation offset for bridge */
> };
>
> to drivers/acpi/ioapic.c to make it compile which appears to be related to:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a49170b552423a3e85fc4f0d778c707402ee4863
>
> which depends on a number of patches from around that time which change acpi/resource.c:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/acpi/resource.c
>
> (from 2015/2/3)
>
> At this point I'm out my depth on how you want to fix this but it does
> appear related to the Braswell changes.
>
> To be clear qemux86 and qemux86-64 don't build at all with this series.
> I'll see if I can just drop the Braswell parts.

I did reproduce the issue here as well, so with any luck, I can sneak
enough time to have this fixed for Monday after all.

Bruce

>
> Cheers,
>
> Richard
>

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Richard Purdie]

On Sat, 2015-05-02 at 23:52 -0400, Bruce Ashfield wrote:
> On 2015-05-02 5:00 AM, Richard Purdie wrote:
> > On Fri, 2015-05-01 at 19:30 -0400, Bruce Ashfield wrote:
> >> On 2015-05-01 6:59 PM, Richard Purdie wrote:
> >>> On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
> >>>> Here is the latest consolidated pull request for the supported linux-yocto
> >>>> kernels.
> >>>>
> >>>>    - We have a refresh of the 3.14-rt support
> >>>>    - bluetooh configuration changes for common-pc/qemux86
> >>>>    - braswell BSP features and fixes
> >>>>    - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
> >>>>
> >>>> I've built and booted these on my local machines and qemu, and
> >>>> everything was sane.
> >>>>
> >>>> The -dev kernel obviously isn't something for deployment yet, but
> >>>> it builds, and forms the base for follow up config changes, features
> >>>> and development work. I built and booted core-image-kernel dev with
> >>>> the 4.1 changes in place.
> >>>
> >>> The autobuilder showed up this for an x32 build :/.
> >>
> >> Can one of the intel folks have a look at this ? I won't be able to get
> >> to it until Tuesday at the earliest.
> >
> > I had a look into this. The issue is that this has been applied:
> >
> > http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.19/commit/?h=standard/base&id=423e98721e048f6c7b925a75448f6c4ecb2b5b69
> >
> > but it needs:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ce793486e23e0162a732c605189c8028e0910e86
> >
> > and the ioapic driver also appears to need:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=ecf5636dcd59cd5508641f995cc4c2bafedbb995
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/patch/?id=62d1141ff34e35de496ba06491c8e854b23b3f3e
> >
> >
> > which meant I also had to add:
> >
> > struct resource_win {
> > 	struct resource res;		/* In master (CPU) address space */
> > 	resource_size_t offset;		/* Translation offset for bridge */
> > };
> >
> > to drivers/acpi/ioapic.c to make it compile which appears to be related to:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=a49170b552423a3e85fc4f0d778c707402ee4863
> >
> > which depends on a number of patches from around that time which change acpi/resource.c:
> >
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/drivers/acpi/resource.c
> >
> > (from 2015/2/3)
> >
> > At this point I'm out my depth on how you want to fix this but it does
> > appear related to the Braswell changes.
> >
> > To be clear qemux86 and qemux86-64 don't build at all with this series.
> > I'll see if I can just drop the Braswell parts.
> 
> I did reproduce the issue here as well, so with any luck, I can sneak
> enough time to have this fixed for Monday after all.

From my perspective there isn't a rush at this point. I've merged the
config changes which unblocked the bluez patches and things are
therefore "flowing" from my perspective, the stable update can wait
until later in the week.

Cheers,

Richard

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Richard Purdie]

On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
> Here is the latest consolidated pull request for the supported linux-yocto
> kernels.
> 
>  - We have a refresh of the 3.14-rt support
>  - bluetooh configuration changes for common-pc/qemux86
>  - braswell BSP features and fixes
>  - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
> 
> I've built and booted these on my local machines and qemu, and
> everything was sane.
> 
> The -dev kernel obviously isn't something for deployment yet, but
> it builds, and forms the base for follow up config changes, features
> and development work. I built and booted core-image-kernel dev with
> the 4.1 changes in place.

There was also a problem with poky-lsb. The idea (as far as I remember)
is that it should be using LTSI rather than the default main kernel so
we could split the testing. Unfortunately it was pointing at 3.10 which
doesn't exist any longer so was using 3.17. I think LTSI is 3.14 so I
updated the PREFERRED_VERSION to that.

This resulted in this failure on the autobuilder:

https://autobuilder.yoctoproject.org/main/builders/nightly-mips-lsb/builds/281/steps/BuildImages/logs/stdio

Basically with qemumips and 3.14. Hopefully not a hard one to fix. If
I've mixed the versions up, let me know which one poky-lsb should be
using.

Cheers,

Richard

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Bruce Ashfield]

On 2015-05-03 5:30 PM, Richard Purdie wrote:
> On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
>> Here is the latest consolidated pull request for the supported linux-yocto
>> kernels.
>>
>>   - We have a refresh of the 3.14-rt support
>>   - bluetooh configuration changes for common-pc/qemux86
>>   - braswell BSP features and fixes
>>   - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
>>
>> I've built and booted these on my local machines and qemu, and
>> everything was sane.
>>
>> The -dev kernel obviously isn't something for deployment yet, but
>> it builds, and forms the base for follow up config changes, features
>> and development work. I built and booted core-image-kernel dev with
>> the 4.1 changes in place.
>
> There was also a problem with poky-lsb. The idea (as far as I remember)
> is that it should be using LTSI rather than the default main kernel so
> we could split the testing. Unfortunately it was pointing at 3.10 which
> doesn't exist any longer so was using 3.17. I think LTSI is 3.14 so I
> updated the PREFERRED_VERSION to that.

Correct on all counts. We did want it to use LTSI, and that is 3.14
at the moment.

>
> This resulted in this failure on the autobuilder:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-mips-lsb/builds/281/steps/BuildImages/logs/stdio
>
> Basically with qemumips and 3.14. Hopefully not a hard one to fix. If

Doesn't look to bad. I'll address this one along with the x32 build
failure on Monday (assuming I get it fixed in the day).

Bruce

> I've mixed the versions up, let me know which one poky-lsb should be
> using.
>
> Cheers,
>
> Richard
>

Re: [PATCH 0/5] linux-yocto: consolidated pull request

[Bruce Ashfield]

On 2015-05-03 05:30 PM, Richard Purdie wrote:
> On Thu, 2015-04-30 at 21:34 -0400, Bruce Ashfield wrote:
>> Here is the latest consolidated pull request for the supported linux-yocto
>> kernels.
>>
>>   - We have a refresh of the 3.14-rt support
>>   - bluetooh configuration changes for common-pc/qemux86
>>   - braswell BSP features and fixes
>>   - Introduction of the 4.1-rc1 -dev kernel (and associated perf fix).
>>
>> I've built and booted these on my local machines and qemu, and
>> everything was sane.
>>
>> The -dev kernel obviously isn't something for deployment yet, but
>> it builds, and forms the base for follow up config changes, features
>> and development work. I built and booted core-image-kernel dev with
>> the 4.1 changes in place.
>
> There was also a problem with poky-lsb. The idea (as far as I remember)
> is that it should be using LTSI rather than the default main kernel so
> we could split the testing. Unfortunately it was pointing at 3.10 which
> doesn't exist any longer so was using 3.17. I think LTSI is 3.14 so I
> updated the PREFERRED_VERSION to that.
>
> This resulted in this failure on the autobuilder:
>
> https://autobuilder.yoctoproject.org/main/builders/nightly-mips-lsb/builds/281/steps/BuildImages/logs/stdio
>
> Basically with qemumips and 3.14. Hopefully not a hard one to fix. If
> I've mixed the versions up, let me know which one poky-lsb should be

FYI: I've fixed the mips build. Looking at x86 now. SRCREV updates
to follow ASAP.

Bruce

> using.
>
> Cheers,
>
> Richard
>