Skip to contentSkip to conversation

linux-yocto: consolidated pull request

PATCH In review Bruce Ashfield 4 participants 27 messages May 1, 2015 – May 7, 2015

lore
Share & tools
lore

Bruce Ashfield

author
#0 lore raw

cover linux-yocto: consolidated pull request

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(-)
Signature · 1 line
2.1.0
author
#1 lore raw

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

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 <[email protected]>
---
 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(-)
meta/recipes-kernel/linux/linux-yocto-rt_3.14.bb +3 -3
index 4b602b1b03f6..23e1688daeda 100644
@@ -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"
meta/recipes-kernel/linux/linux-yocto-tiny_3.14.bb +2 -2
index afcc4dd6206c..1d999650611c 100644
@@ -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}"
meta/recipes-kernel/linux/linux-yocto_3.14.bb +9 -9
index b71aea2b18e9..fa433b61c821 100644
@@ -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"
Signature · 1 line
2.1.0
author
#2 lore raw

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

In reply to Bruce Ashfield

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

Signed-off-by Bruce Ashfield <[email protected]>
---
 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(-)
meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb +1 -1
index 15fc536e0a41..1f91471dd622 100644
@@ -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}"
meta/recipes-kernel/linux/linux-yocto_3.19.bb +1 -1
index e47e22b39695..6ddbe8c59336 100644
@@ -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"
Signature · 1 line
2.1.0
author
#3 lore raw

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

In reply to 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 <[email protected]>
---
 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(-)
meta/recipes-kernel/linux/linux-yocto-tiny_3.19.bb +1 -1
index 1f91471dd622..691637563986 100644
@@ -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}"
meta/recipes-kernel/linux/linux-yocto_3.19.bb +8 -8
index 6ddbe8c59336..ccba54424b10 100644
@@ -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"
Signature · 1 line
2.1.0
author
#4 lore raw

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

In reply to 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 <[email protected]>
---
 meta/recipes-kernel/perf/perf.bb | 3 +++
 1 file changed, 3 insertions(+)
meta/recipes-kernel/perf/perf.bb +3 -0
index 420fe6b57aba..eb273740ee10 100644
@@ -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
Signature · 1 line
2.1.0
author
#5 lore raw

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

In reply to Bruce Ashfield
Signed-off-by Bruce Ashfield <[email protected]>
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
meta/recipes-kernel/linux/linux-yocto-dev.bb +1 -1
index ba88fd7dc337..588a89f6411b 100644
@@ -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}"
Signature · 1 line
2.1.0
#6 lore raw
In reply to Bruce Ashfield
Quoted 8 lines · 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).

Quoted 7 lines

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

author
#7 lore raw
Quoted 12 lines · Richard Purdie
Quoted 11 lines · 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.

Quoted 6 lines
Quoted 4 lines

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

Quoted 7 lines

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

Cheers,

Richard

#8 lore raw
Quoted 11 lines · Bruce Ashfield
Quoted 10 lines · Richard Purdie
Quoted 9 lines · 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.

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

Quoted 25 lines
Quoted 6 lines
Quoted 4 lines

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

Quoted 7 lines

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

Cheers,

Richard

Signature · 4 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 1 line
Martin 'JaMa' Jansa     jabber: [email protected]
author
#9 lore raw
Quoted 13 lines · Martin Jansa
Quoted 11 lines · Bruce Ashfield
Quoted 10 lines · Richard Purdie
Quoted 9 lines · 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.

Quoted 2 lines

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

Quoted 27 lines
Quoted 26 lines
Quoted 7 lines
Quoted 5 lines

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

Quoted 7 lines

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

Cheers,

Richard

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#10 lore raw
Quoted 14 lines · Bruce Ashfield
Quoted 13 lines · Martin Jansa
Quoted 11 lines · Bruce Ashfield
Quoted 10 lines · Richard Purdie
Quoted 9 lines · 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.

Quoted 7 lines
Quoted 2 lines

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/

Quoted 27 lines
Quoted 26 lines
Quoted 25 lines
Quoted 6 lines
Quoted 4 lines

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

Quoted 7 lines

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

Cheers,

Richard

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 1 line
Martin 'JaMa' Jansa     jabber: [email protected]
author
#11 lore raw
Quoted 18 lines · Martin Jansa
Quoted 17 lines · Bruce Ashfield
Quoted 15 lines · Martin Jansa
Quoted 11 lines · Bruce Ashfield
Quoted 10 lines · Richard Purdie
Quoted 9 lines · 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.

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

Quoted 7 lines
Quoted 4 lines

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

Quoted 45 lines

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/

Quoted 27 lines
Quoted 26 lines
Quoted 25 lines
Quoted 6 lines
Quoted 4 lines

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

Quoted 7 lines

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

Cheers,

Richard

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#12 lore raw
Quoted 24 lines · Bruce Ashfield
Quoted 23 lines · Martin Jansa
Quoted 21 lines · Bruce Ashfield
Quoted 13 lines · Martin Jansa
Quoted 11 lines · Bruce Ashfield
Quoted 10 lines · Richard Purdie
Quoted 9 lines · 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.

Quoted 2 lines

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.

Quoted 7 lines
Quoted 2 lines

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.

Quoted 46 lines
Quoted 45 lines

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/

Quoted 27 lines
Quoted 26 lines
Quoted 25 lines
Quoted 6 lines
Quoted 4 lines

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

Quoted 7 lines

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

Cheers,

Richard

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 1 line
Martin 'JaMa' Jansa     jabber: [email protected]
#13 lore raw
Quoted 11 lines · Martin Jansa
Quoted 5 lines · Bruce Ashfield

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

#14 lore raw
Quoted 6 lines · Richard Purdie
Quoted 5 lines · Martin Jansa
Quoted 4 lines · Bruce Ashfield

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.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

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).

Quoted 5 lines

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

Quoted 8 lines

* 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).

Quoted 7 lines

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

Signature · 1 line
Martin 'JaMa' Jansa     jabber: [email protected]
author
#15 lore raw
Quoted 40 lines · Martin Jansa
Quoted 6 lines · Richard Purdie
Quoted 5 lines · Martin Jansa
Quoted 4 lines · Bruce Ashfield

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.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

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).

Quoted 5 lines

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

Quoted 8 lines

* 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?

Quoted 6 lines

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

Quoted 9 lines
Quoted 8 lines

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

#16 lore raw
Quoted 8 lines · Bruce Ashfield
Quoted 6 lines · Martin Jansa

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).

Quoted 8 lines

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

#17 lore raw

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).

Quoted 34 lines · Richard Purdie
Quoted 2 lines · Bruce Ashfield
Quoted 1 line · Martin Jansa

I've used master-next week or two ago (mostly to test bluez4 and

python3

Quoted 6 lines
Quoted 5 lines

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).

Quoted 8 lines

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

author
#18 lore raw
Quoted 3 lines · Martin Jansa

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

Quoted 38 lines

On Wed, May 6, 2015 at 11:32 PM, Richard Purdie <[email protected] <mailto:[email protected]>> 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

#19 lore raw
In reply to Martin Jansa
Quoted 7 lines · Martin Jansa

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

#20 lore raw
In reply to Bruce Ashfield
Quoted 18 lines · Bruce Ashfield
Quoted 17 lines · Richard Purdie
Quoted 15 lines · 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.

Quoted 4 lines
Quoted 1 line

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

author
#21 lore raw
Quoted 53 lines · Richard Purdie
Quoted 18 lines · Bruce Ashfield
Quoted 17 lines · Richard Purdie
Quoted 15 lines · 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.

Quoted 4 lines
Quoted 1 line

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

Quoted 7 lines

(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

Quoted 5 lines

Cheers,

Richard

author
#22 lore raw
In reply to Richard Purdie
Quoted 53 lines · Richard Purdie
Quoted 18 lines · Bruce Ashfield
Quoted 17 lines · Richard Purdie
Quoted 15 lines · 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.

Quoted 4 lines
Quoted 1 line

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

Quoted 7 lines

(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

Quoted 5 lines

Cheers,

Richard

#23 lore raw
Quoted 56 lines · Bruce Ashfield
Quoted 55 lines · Richard Purdie
Quoted 18 lines · Bruce Ashfield
Quoted 17 lines · Richard Purdie
Quoted 15 lines · 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.

Quoted 4 lines
Quoted 1 line

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)

Quoted 8 lines
Quoted 5 lines

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

#24 lore raw
In reply to Bruce Ashfield
Quoted 8 lines · 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).

Quoted 7 lines

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

author
#25 lore raw
Quoted 17 lines · Richard Purdie
Quoted 8 lines · 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).

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 6 lines

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

Quoted 7 lines

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

Cheers,

Richard

author
#26 lore raw
In reply to Richard Purdie
Quoted 23 lines · Richard Purdie
Quoted 8 lines · 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).

Quoted 7 lines

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.

Quoted 6 lines

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

Quoted 6 lines

using.

Cheers,

Richard