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