Re: [PATCH 4.8 00/67] 4.8.11-stable review

[Javier Martinez Canillas]

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