On Wed, Jul 23, 2014 at 12:58 AM, Kevin Hilman khilman@linaro.org wrote:
On Tue, Jul 22, 2014 at 6:06 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 07/21/2014 11:23 PM, Kevin's boot bot wrote:
Full logs here: http://armcloud.us/kernel-ci/arm-soc/v3.16-rc5-772-gdf8c436
Tree/Branch: arm-soc Git describe: v3.16-rc5-772-gdf8c436 Failed boot tests ================= legacy,dm365evm: FAIL: arm-davinci_all_defconfig http://armcloud.us/kernel-ci/arm-soc/v3.16-rc5-772-gdf8c436/arm-davinci_all_... da850-evm: FAIL: arm-davinci_all_defconfig http://armcloud.us/kernel-ci/arm-soc/v3.16-rc5-772-gdf8c436/arm-davinci_all_... tegra124-jetson-tk1: FAIL: arm-tegra_defconfig http://armcloud.us/kernel-ci/arm-soc/v3.16-rc5-772-gdf8c436/arm-tegra_defcon... tegra30-beaver: FAIL: arm-tegra_defconfig http://armcloud.us/kernel-ci/arm-soc/v3.16-rc5-772-gdf8c436/arm-tegra_defcon... tegra124-jetson-tk1: FAIL: arm-multi_v7_defconfig+CONFIG_ARM_LPAE=y http://armcloud.us/kernel-ci/arm-soc/v3.16-rc5-772-gdf8c436/arm-multi_v7_def...
...
I assume these mass failures are some kind of initrd generation issue in yur test scripts? The logs I looked at all failed with roughly:
Yes, They were all being mistakenly passed a big-endian rootfs. I'm on vacation, but tried a quick fix so the scripts can deal with the old way of detecting a big-endian kernel (looking for 'setend be') and the new way (looking for the 0x04030201 magic number), but goofed it up, clearly proving that I should've left my scripts alone and just continued my vacation. :)
OK, I (re)fixed things up and respun the latest mainline and arm-soc boot tests and things look more or less sane again. Looks like some things need bisecting on exynos, but hopefully someone else will do that as I'm going back to my vacation and hoping my automated scripts keep making it look like I'm doing real work. ;)
Kevin