Hello, On 11/28/2016 03:05 PM, Kevin Hilman wrote: > [ + Exynos maintainers ] > > Sorry for the lag, I realize that this stable release is already made, > but following-up here anyways, and including Exynos maintainers so they > are aware of the (possible) regressions in stable/linux-4.8.y. > > kernelci.org bot <bot@xxxxxxxxxxxx> writes: > >> stable-rc boot: 207 boots: 8 failed, 196 passed with 3 offline (v4.8.10-68-g5b1cb43a9ac7) >> >> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.8.10-68-g5b1cb43a9ac7/ >> Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.8.10-68-g5b1cb43a9ac7/ >> >> Tree: stable-rc >> Branch: local/linux-4.8.y >> Git Describe: v4.8.10-68-g5b1cb43a9ac7 >> Git Commit: 5b1cb43a9ac7f608fdfc590c139aa66ead8d19ed >> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git >> Tested: 57 unique boards, 18 SoC families, 30 builds out of 207 >> >> Boot Failures Detected: https://kernelci.org/boot/?v4.8.10-68-g5b1cb43a9ac7&fail >> >> arm: >> >> multi_v7_defconfig+CONFIG_SMP=n: >> exynos5250-snow: 1 failed lab > > This one is not new, it's has been failing for awhile in v4.8. The > details show a bit more of the history: > https://kernelci.org/boot/id/58379c6e59b514a607f03beb/ > There's already a fix for this issue queued in the media tree: https://git.linuxtv.org/media_tree.git/commit/?id=3467c9a7e7f9 The commit has a Fixes tag so it should be backported to stable once it lands to mainline. I've just pinged to Mauro about it. >> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: >> at91-sama5d4_xplained: 1 failed lab > > This one is not a regression, it's a board with a small amount of memory > that needs to be blacklisted for the large CONFIG_PROVE_LOCKING=y > kernels. > >> exynos_defconfig: >> exynos5250-arndale: 1 failed lab > > This one looks like an actual regression, as it was passing in v4.8.10: This seems to be the issue Viresh reported and fixed with this patch: https://lkml.org/lkml/2016/10/27/216 > https://kernelci.org/boot/id/583797b359b51493acf03bf2/ > Yes, but IIUC the issue was just not triggered there because the devm_regulator_bulk_get() succeed and so the resource cleanup never happened. IOW, the bug is also present on older stable kernels but it seems to work just because the driver probe hasn't been deferred AFAICT. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html