next/master boot: 273 boots: 63 failed, 209 passed with 1 untried/unknown (next-20171106)

[Robin Murphy]

On 08/11/17 16:23, Mikko Perttunen wrote:
> On 08.11.2017 17:55, Robin Murphy wrote:
>>
>>
>> On 08/11/17 15:19, Guillaume Tucker wrote:
>>> On 07/11/17 11:43, Guillaume Tucker wrote:
>>>> On 07/11/17 10:55, Mark Brown wrote:
>>>>> On Tue, Nov 07, 2017 at 10:12:59AM +0000, Jon Hunter wrote:
>>>>>> On 06/11/17 19:17, Mark Brown wrote:
>>>>>
>>>>>>>>     multi_v7_defconfig:
>>>>>>>>         tegra124-nyan-big:
>>>>>>>>             lab-collabora: failing since 2 days (last pass:
>>>>>>>> next-20171102 - first fail: next-20171103)
>>>>>
>>>>>> Thanks for the report. I have been looking into a failure on nyan-big
>>>>>> [0], but this one looks like a new failure. I will take a look.
>>>>>
>>>>> Guillaume Tucker has been bisecting this with the shiny new bisection
>>>>> code he's testing, he was saying on IRC he thinks he's found the
>>>>> offending commit:
>>>>>
>>>>>
>>>>> https://people.collabora.com/~gtucker/tmp/bisect-tegra-4.14.rc8-next-20171106.txt 
>>>>>
>>>>>
>>>>>
>>>>> (not CCing Johannes yet)
>>>>
>>>> Please take this with a pinch of salt, I'm now running some extra
>>>> boot tests to prove it.  If you look at this log, all the boots
>>>> passed which is a bit suspicious.  I did build and boot the
>>>> revision it found with multi_v7_defconfig on tegra124 and it
>>>> passed, so it looks like this commit may not have anything to do
>>>> with the boot failure.  The automated bisection is still experimental.
>>>>
>>>> Passing LAVA boot test with this revision:
>>>>
>>>>   https://lava.collabora.co.uk/scheduler/job/976375
>>>>
>>>> I've started a slightly different bisection job now on
>>>> next-20171107 and the common ancestor between next and mainline,
>>>> results can take a few hours to come back.
>>>
>>> After a few more automated bisection attempts and a bug fix in
>>> LAVA, I've now found at least one potentially breaking commit:
>>>
>>>    commit d89e2378a97fafdc74cbf997e7c88af75b81610a
>>>    Author: Robin Murphy <robin.murphy at arm.com>
>>>    Date:   Thu Oct 12 16:56:14 2017 +0100
>>>
>>>        drivers: flag buses which demand DMA configuration
>>>
>>>
>>> I've run some boot tests manually with this revision and then
>>> also after reverting it in-place, these respectively failed and
>>> passed:
>>>
>>>    * d89e2378, failed:
>>>      https://lava.collabora.co.uk/scheduler/job/978968
>>>
>>>    * d89e2378 reverted, passed:
>>>      https://lava.collabora.co.uk/scheduler/job/978969
>>>
>>>
>>> I then went on and tried the same but on top of next-20171108 and
>>> found that they both failed
>>>
>>>    * next-20171108, failed:
>>>      https://lava.collabora.co.uk/scheduler/job/979063
>>>
>>>    * next-20171108 with d89e2378 reverted, failed as well:
>>>      https://lava.collabora.co.uk/scheduler/job/979167
>>>
>>>
>>> So this shows there is almost certainly another offending commit
>>> in -next.  The errors in both cases are not quite the same, the
>>> last one is triggered by a BUG whereas the first one is a NULL
>>> pointer (I haven't looked any further).  Also I don't think
>>> there's any fix for d89e2378a97fafdc74cbf997e7c88af75b81610a
>>> which is currently still in next.
>>
>> The fix was actually posted before said commit was even written:
>>
>> https://patchwork.kernel.org/patch/9967847/
>>
>> What is currently queued in the DMA tree fell out of the discussion on
>> patch 2 of that series, but I kind of assumed the host1x folks would
>> still take patch 1; I guess that hasn't happened.
> 
> I am seeing this patch in linux-next, though:

Phew, great! Perhaps I should have actually looked :)

So for this case it seems it's only the DRM tree being merged into -next 
after the DMA mapping tree which is hurting Guillaume's bisection. 
That's unfortunate, but it least it's not an a complete showstopper.

Robin.

> commit 2fb0dceb69ce957f01bdb6fddf7baf4c4b9cbc0d
> Author:     Mikko Perttunen <mperttunen at nvidia.com>
> AuthorDate: Sun Sep 24 12:04:53 2017 +0300
> Commit:     Thierry Reding <treding at nvidia.com>
> CommitDate: Fri Oct 20 14:19:51 2017 +0200
> 
>      gpu: host1x: Call of_dma_configure() after setting bus
> 
>      of_dma_configure() now checks the device's bus before configuring 
> it, so
>      we need to set the device's bus before calling.
> 
>      Signed-off-by: Mikko Perttunen <mperttunen at nvidia.com>
>      Signed-off-by: Thierry Reding <treding at nvidia.com>
> 
> 
> Mikko
> 
>>
>> Robin.
>>
>>>
>>> Note: This happens to be a very good example of running a
>>> kernelci.org bisection on a real issue, it's quite a bit of a
>>> pipe cleaner.  I'll now see if there's a way to bisect what looks
>>> like another breaking change in-between.
>>>
>>> Guillaume
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html