linux-yocto-bsps: bump reference BSPs to v3.4.11

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

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

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]

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

index 6a6176e..0a70143 100644
@@ -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

Hi Bruce,

3.4.13 is out maybe worth to directly update to the latest stable ?

Best regards,
Eric

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

that's right, upgrading to latest stable can be done in a later release.

Eric