Messages in this thread | | | From | Nick Desaulniers <> | Date | Wed, 1 Apr 2020 17:26:29 -0700 | Subject | Re: [PATCH v3] bitfield.h: add FIELD_MAX() and field_max() |
| |
On Wed, Apr 1, 2020 at 4:18 PM Alex Elder <elder@linaro.org> wrote: > > On 4/1/20 5:26 PM, Nick Desaulniers wrote: > > > > mainline is hosed for aarch64 due to some dtc failures. I'm not sure > > how TCWG's CI chooses the bisection starting point, but if mainline > > was broken, and it jumped back say 300 commits, then the automated > > bisection may have converged on your first patch, but not the second. > > This is similar to the situation I discussed with Maxim this > morning. A different failure (yes, DTC related) led to an > automated bisect process, which landed on my commit. And my > commit unfortunately has the the known issue that was later > corrected. > > Maxim said this was what started the automated bisect: > === > +# 00:01:41 make[2]: *** [arch/arm64/boot/dts/ti/k3-am654-base-board.dtb] Error 2 > +# 00:01:41 make[2]: *** [arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dtb] Error 2 > +# 00:01:41 make[1]: *** [arch/arm64/boot/dts/ti] Error 2 > +# 00:01:41 make: *** [dtbs] Error 2
DTC thread: https://lore.kernel.org/linux-arm-kernel/20200401223500.224253-1-ndesaulniers@google.com/
Maxim, can you describe how the last known good sha is chosen? If you persist anything between builds, like ccache dir, maybe you could propagate a sha of the last successful build, updating it if no regression occurred? Then that can always be a precise last known good sha. Though I don't know if the merge commits complicate this. -- Thanks, ~Nick Desaulniers
| |