[PATCH 0/1] linux-yocto-bsps: bump reference BSPs to v3.4.11

[PATCH 0/1] linux-yocto-bsps: bump reference BSPs to v3.4.11

[Bruce Ashfield]

Richard/Saul,

I'm out of the office until Wednesday, but wanted to send this
change before then. I'm attempting to relay this via gmail smtp,
so I hope the patches come through properly.

We were looking at YOCTO 3186 (which is a segfault when running
rpm commands), and Mark Asselstine bisected it to a regression
introduced in v3.4.10 which was subsequently fixed in 3.4.11.

Luckily I had already bumped the qemu BSPs to 3.4.11, so updating
the hardware reference boards to the already in tree version fixes
the regression.

(random note: -stable is up to 3.4.13, but there are no firm plans
to send those changes at this point).

Send any questions about this to my gmail account, since I won't
have access to my work email until Wednesday.

Cheers,

Bruce

cc: Mark Asselstine <mark.asselstine@windriver.com>

The following changes since commit eb8ac50d58575be3e04c4decc5b0e2d80381be9b:

  documentation: dev-manual - mentioned SRC_URI in the kernel example (2012-10-07 13:15:37 +0100)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib zedd/yocto-bsps
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/yocto-bsps

Bruce Ashfield (1):
  linux-yocto-bsps: update hardware reference BSPs to v3.4.11

 .../recipes-kernel/linux/linux-yocto_3.4.bbappend  |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)

-- 
1.7.5.4

[PATCH 1/1] linux-yocto-bsps: update hardware reference BSPs to v3.4.11

[Bruce Ashfield]

The hardware reference BSPs are missing the update to 3.4.11
that the qemu* machines received several weeks ago.

Bumping to 3.4.11 specifically addresses the segfaults being
seen with rpm on the beagleboard.

[YOCTO #3186]

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 .../recipes-kernel/linux/linux-yocto_3.4.bbappend  |    9 ++++-----
 1 files changed, 4 insertions(+), 5 deletions(-)

diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.4.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.4.bbappend
index 6a6176e..0a70143 100644
--- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.4.bbappend
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.4.bbappend
@@ -3,11 +3,10 @@ KBRANCH_routerstationpro = "standard/routerstationpro"
 KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
 KBRANCH_beagleboard = "standard/beagleboard"
 
-SRCREV_machine_atom-pc ?= "59c3ff750831338d05ab67d5efd7fc101c451aff"
-SRCREV_machine_routerstationpro ?= "009935376be574746446f4bead6f0fb7b40d6d79"
-SRCREV_machine_mpc8315e-rdb ?= "6b18b6f483716b757c7c8642fa3792235118bb63"
-SRCREV_machine_beagleboard ?= "59c3ff750831338d05ab67d5efd7fc101c451aff"
-
+SRCREV_machine_atom-pc ?= "3fa06aa29078fdb2af431de2d3fdae7d281ba85f"
+SRCREV_machine_routerstationpro ?= "d041a78adac8cefd70ba42c316c07069b7b83def"
+SRCREV_machine_mpc8315e-rdb ?= "b7f8afa34eb1f3de110c0acfd6fb44bdae200e6a"
+SRCREV_machine_beagleboard ?= "3fa06aa29078fdb2af431de2d3fdae7d281ba85f"
 
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 COMPATIBLE_MACHINE_routerstationpro = "routerstationpro"
-- 
1.7.5.4

Re: [PATCH 1/1] linux-yocto-bsps: update hardware reference BSPs to v3.4.11

[Eric Bénard]

Hi Bruce,

Le Sun,  7 Oct 2012 23:41:31 -0400,
Bruce Ashfield <bruce.ashfield@windriver.com> a écrit :

> The hardware reference BSPs are missing the update to 3.4.11
> that the qemu* machines received several weeks ago.
> 
> Bumping to 3.4.11 specifically addresses the segfaults being
> seen with rpm on the beagleboard.
> 
3.4.13 is out maybe worth to directly update to the latest stable ?

Best regards,
Eric

Re: [PATCH 1/1] linux-yocto-bsps: update hardware reference BSPs to v3.4.11

[Richard Purdie]

On Mon, 2012-10-08 at 10:24 +0200, Eric Bénard wrote:
> Hi Bruce,
> 
> Le Sun,  7 Oct 2012 23:41:31 -0400,
> Bruce Ashfield <bruce.ashfield@windriver.com> a écrit :
> 
> > The hardware reference BSPs are missing the update to 3.4.11
> > that the qemu* machines received several weeks ago.
> > 
> > Bumping to 3.4.11 specifically addresses the segfaults being
> > seen with rpm on the beagleboard.
> > 
> 3.4.13 is out maybe worth to directly update to the latest stable ?

At this point, 3.4.11 has had some testing, we've not done any testing
with 3.4.13.

The trouble is we're due -rc4 tomorrow which is our final build for the
release. I'm extremely reluctant to make *any* kernel changes at this
point but it looks like this segfault issue is going to force my hand
and I'm going to have to take the update.

I'm already doing some mitigation type work of pretesting the builds in
advance to try and ensure -rc4 is successful and we can take this
change. Adding 3.4.13 into the mix sounds nice in theory but
substantially increases the risk. Keep in mind this bug we're trying to
fix crept in through the "stable" updates in the first place :(

Cheers,

Richard

Re: [PATCH 1/1] linux-yocto-bsps: update hardware reference BSPs to v3.4.11

[Eric Bénard]

Le Mon, 08 Oct 2012 10:23:52 +0100,
Richard Purdie <richard.purdie@linuxfoundation.org> a écrit :

> On Mon, 2012-10-08 at 10:24 +0200, Eric Bénard wrote:
> > Hi Bruce,
> > 
> > Le Sun,  7 Oct 2012 23:41:31 -0400,
> > Bruce Ashfield <bruce.ashfield@windriver.com> a écrit :
> > 
> > > The hardware reference BSPs are missing the update to 3.4.11
> > > that the qemu* machines received several weeks ago.
> > > 
> > > Bumping to 3.4.11 specifically addresses the segfaults being
> > > seen with rpm on the beagleboard.
> > > 
> > 3.4.13 is out maybe worth to directly update to the latest stable ?
> 
> At this point, 3.4.11 has had some testing, we've not done any testing
> with 3.4.13.
> 
> The trouble is we're due -rc4 tomorrow which is our final build for the
> release. I'm extremely reluctant to make *any* kernel changes at this
> point but it looks like this segfault issue is going to force my hand
> and I'm going to have to take the update.
> 
> I'm already doing some mitigation type work of pretesting the builds in
> advance to try and ensure -rc4 is successful and we can take this
> change. Adding 3.4.13 into the mix sounds nice in theory but
> substantially increases the risk. Keep in mind this bug we're trying to
> fix crept in through the "stable" updates in the first place :(
> 
that's right, upgrading to latest stable can be done in a later release.

Eric