"kernelci.org bot" <[email protected]> writes:
> next/master boot bisection: next-20190617 on sun8i-h2-plus-orangepi-zero
>
> Summary:
> Start: a125097c8410 Add linux-next specific files for 20190617
> Details: https://kernelci.org/boot/id/5d07987659b51412add51503
> Plain log: https://storage.kernelci.org//next/master/next-20190617/arm/multi_v7_defconfig/gcc-8/lab-baylibre/boot-sun8i-h2-plus-orangepi-zero.txt
> HTML log: https://storage.kernelci.org//next/master/next-20190617/arm/multi_v7_defconfig/gcc-8/lab-baylibre/boot-sun8i-h2-plus-orangepi-zero.html
> Result: ce4ab73ab0c2 net: stmmac: drop the reset delays from struct stmmac_mdio_bus_data
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: next
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> Branch: master
> Target: sun8i-h2-plus-orangepi-zero
> CPU arch: arm
> Lab: lab-baylibre
> Compiler: gcc-8
> Config: multi_v7_defconfig
> Test suite: boot
>
> Breaking commit found:
>
> -------------------------------------------------------------------------------
> commit ce4ab73ab0c27c6a3853695aa8ec0f453c6329cd
> Author: Martin Blumenstingl <[email protected]>
> Date: Sat Jun 15 12:09:31 2019 +0200
>
> net: stmmac: drop the reset delays from struct stmmac_mdio_bus_data
>
> Only OF platforms use the reset delays and these delays are only read in
> stmmac_mdio_reset(). Move them from struct stmmac_mdio_bus_data to a
> stack variable inside stmmac_mdio_reset() because that's the only usage
> of these delays.
>
> Signed-off-by: Martin Blumenstingl <[email protected]>
> Signed-off-by: David S. Miller <[email protected]>
This seems to have broken on several sunxi SoCs, but also a MIPS SoC
(pistachio_marduk):
https://storage.kernelci.org/next/master/next-20190618/mips/pistachio_defconfig/gcc-8/lab-baylibre-seattle/boot-pistachio_marduk.html
Kevin
On Tue, Jun 18, 2019 at 6:53 PM Kevin Hilman <[email protected]> wrote:
[...]
> This seems to have broken on several sunxi SoCs, but also a MIPS SoC
> (pistachio_marduk):
>
> https://storage.kernelci.org/next/master/next-20190618/mips/pistachio_defconfig/gcc-8/lab-baylibre-seattle/boot-pistachio_marduk.html
today I learned why initializing arrays on the stack is important
too bad gcc didn't warn that I was about to shoot myself (or someone
else) in the foot :/
I just sent a fix: [0]
sorry for this issue and thanks to Kernel CI for even pointing out the
offending commit (this makes things a lot easier than just yelling
that "something is broken")
Martin
[0] https://patchwork.ozlabs.org/patch/1118313/
On 18/06/2019 21:42, Martin Blumenstingl wrote:
> On Tue, Jun 18, 2019 at 6:53 PM Kevin Hilman <[email protected]> wrote:
> [...]
>> This seems to have broken on several sunxi SoCs, but also a MIPS SoC
>> (pistachio_marduk):
>>
>> https://storage.kernelci.org/next/master/next-20190618/mips/pistachio_defconfig/gcc-8/lab-baylibre-seattle/boot-pistachio_marduk.html
> today I learned why initializing arrays on the stack is important
> too bad gcc didn't warn that I was about to shoot myself (or someone
> else) in the foot :/
>
> I just sent a fix: [0]
>
> sorry for this issue and thanks to Kernel CI for even pointing out the
> offending commit (this makes things a lot easier than just yelling
> that "something is broken")
Glad that helped :)
If you would be so kind as to credit our robot friend in your
patch, it'll be forever grateful:
Reported-by: "kernelci.org bot" <[email protected]>
Thanks,
Guillaume
> Martin
>
>
> [0] https://patchwork.ozlabs.org/patch/1118313/
>
Hi Guillaume,
On Tue, Jun 18, 2019 at 10:53 PM Guillaume Tucker
<[email protected]> wrote:
>
> On 18/06/2019 21:42, Martin Blumenstingl wrote:
> > On Tue, Jun 18, 2019 at 6:53 PM Kevin Hilman <[email protected]> wrote:
> > [...]
> >> This seems to have broken on several sunxi SoCs, but also a MIPS SoC
> >> (pistachio_marduk):
> >>
> >> https://storage.kernelci.org/next/master/next-20190618/mips/pistachio_defconfig/gcc-8/lab-baylibre-seattle/boot-pistachio_marduk.html
> > today I learned why initializing arrays on the stack is important
> > too bad gcc didn't warn that I was about to shoot myself (or someone
> > else) in the foot :/
> >
> > I just sent a fix: [0]
> >
> > sorry for this issue and thanks to Kernel CI for even pointing out the
> > offending commit (this makes things a lot easier than just yelling
> > that "something is broken")
>
> Glad that helped :)
>
> If you would be so kind as to credit our robot friend in your
> patch, it'll be forever grateful:
>
> Reported-by: "kernelci.org bot" <[email protected]>
sure
do you want me to re-send my other patch or should I just reply to it
adding the Reported-by tag and hope that Dave will catch it when
applying the patch?
in either case: I did mention in the patch description that Kernel CI caught it
by the way: I didn't know how to credit the Kernel CI bot.
syzbot / syzkaller makes that bit easy as it's mentioned in the
generated email, see [0] for a (random) example
have you considered adding the Reported-by to the generated email?
Martin
[0] https://lkml.org/lkml/2019/4/19/638
Hi Martin,
On 18/06/2019 21:58, Martin Blumenstingl wrote:
> Hi Guillaume,
>
> On Tue, Jun 18, 2019 at 10:53 PM Guillaume Tucker
> <[email protected]> wrote:
>>
>> On 18/06/2019 21:42, Martin Blumenstingl wrote:
>>> On Tue, Jun 18, 2019 at 6:53 PM Kevin Hilman <[email protected]> wrote:
>>> [...]
>>>> This seems to have broken on several sunxi SoCs, but also a MIPS SoC
>>>> (pistachio_marduk):
>>>>
>>>> https://storage.kernelci.org/next/master/next-20190618/mips/pistachio_defconfig/gcc-8/lab-baylibre-seattle/boot-pistachio_marduk.html
>>> today I learned why initializing arrays on the stack is important
>>> too bad gcc didn't warn that I was about to shoot myself (or someone
>>> else) in the foot :/
>>>
>>> I just sent a fix: [0]
>>>
>>> sorry for this issue and thanks to Kernel CI for even pointing out the
>>> offending commit (this makes things a lot easier than just yelling
>>> that "something is broken")
>>
>> Glad that helped :)
>>
>> If you would be so kind as to credit our robot friend in your
>> patch, it'll be forever grateful:
>>
>> Reported-by: "kernelci.org bot" <[email protected]>
> sure
> do you want me to re-send my other patch or should I just reply to it
> adding the Reported-by tag and hope that Dave will catch it when
> applying the patch?
Well that's no big deal so replying would already be great. The
important part is that the fix gets applied.
> in either case: I did mention in the patch description that Kernel CI caught it
I see, thanks!
> by the way: I didn't know how to credit the Kernel CI bot.
> syzbot / syzkaller makes that bit easy as it's mentioned in the
> generated email, see [0] for a (random) example
> have you considered adding the Reported-by to the generated email?
Yes, we've got some bugs to fix first but that will be added to
the email report soon (next week I guess). Thanks for the
suggestion though.
Guillaume
> [0] https://lkml.org/lkml/2019/4/19/638