On Fri, Mar 01, 2019 at 09:25:24AM +0100, Guillaume Tucker wrote: > On 01/03/2019 00:55, Dan Williams wrote: > > On Thu, Feb 28, 2019 at 3:14 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > >> > >> On Tue, 26 Feb 2019 16:04:04 -0800 Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > >> > >>> On Tue, Feb 26, 2019 at 4:00 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > >>>> > >>>> On Fri, 15 Feb 2019 18:51:51 +0000 Mark Brown <broonie@xxxxxxxxxx> wrote: > >>>> > >>>>> On Fri, Feb 15, 2019 at 10:43:25AM -0800, Andrew Morton wrote: > >>>>>> On Fri, 15 Feb 2019 10:20:10 -0800 (PST) "kernelci.org bot" <bot@xxxxxxxxxxxx> wrote: > >>>>> > >>>>>>> Details: https://kernelci.org/boot/id/5c666ea959b514b017fe6017 > >>>>>>> Plain log: https://storage.kernelci.org//next/master/next-20190215/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-7/lab-collabora/boot-am335x-boneblack.txt > >>>>>>> HTML log: https://storage.kernelci.org//next/master/next-20190215/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-7/lab-collabora/boot-am335x-boneblack.html > >>>>> > >>>>>> Thanks. > >>>>> > >>>>>> But what actually went wrong? Kernel doesn't boot? > >>>>> > >>>>> The linked logs show the kernel dying early in boot before the console > >>>>> comes up so yeah. There should be kernel output at the bottom of the > >>>>> logs. > >>>> > >>>> I assume Dan is distracted - I'll keep this patchset on hold until we > >>>> can get to the bottom of this. > >>> > >>> Michal had asked if the free space accounting fix up addressed this > >>> boot regression? I was awaiting word on that. > >> > >> hm, does bot@xxxxxxxxxxxx actually read emails? Let's try info@ as well.. > > bot@xxxxxxxxxxxx is not person, it's a send-only account for > automated reports. So no, it doesn't read emails. > > I guess the tricky point here is that the authors of the commits > found by bisections may not always have the hardware needed to > reproduce the problem. So it needs to be dealt with on a > case-by-case basis: sometimes they do have the hardware, > sometimes someone else on the list or on CC does, and sometimes > it's better for the people who have access to the test lab which > ran the KernelCI test to deal with it. > > This case seems to fall into the last category. As I have access > to the Collabora lab, I can do some quick checks to confirm > whether the proposed patch does fix the issue. I hadn't realised > that someone was waiting for this to happen, especially as the > BeagleBone Black is a very common platform. Sorry about that, > I'll take a look today. > > It may be a nice feature to be able to give access to the > KernelCI test infrastructure to anyone who wants to debug an > issue reported by KernelCI or verify a fix, so they won't need to > have the hardware locally. Something to think about for the > future. Another thing to consider is adding "earlyprintk debug" to the kernel command line for the boot tests. > >> Is it possible to determine whether this regression is still present in > >> current linux-next? > > I'll try to re-apply the patch that caused the issue, then see if > the suggested change fixes it. As far as the current linux-next > master branch is concerned, KernelCI boot tests are passing fine > on that platform. > > Guillaume > -- Sincerely yours, Mike.
