On 01/10/2022 19:10, Petr Vorel wrote: > On Sat, 1 Oct 2022 at 10:52, Krzysztof Kozlowski > <krzysztof.kozlowski@xxxxxxxxxx> wrote: >> >> On 30/09/2022 23:39, Petr Vorel wrote: >>> I'm sorry, forget to add links. >>> Petr >>> >>> [1] https://gitlab.com/-/snippets/2420133 >>> [2] https://gitlab.com/postmarketOS/pmaports/-/blob/master/main/postmarketos-mkinitfs/init_functions.sh#L514-523 >>> [3] https://gitlab.com/postmarketOS/pmaports/-/blob/master/main/postmarketos-mkinitfs-hook-debug-shell/20-debug-shell.sh >>> [4] https://gitlab.com/-/snippets/2420128 >>> >>> On Fri, 30 Sept 2022 at 23:30, Petr Vorel <petr.vorel@xxxxxxxxx> wrote: >>>> >>>> Hi all, >>>> >>>> [ sorry for sending mail twice, now as plain text. I should move away >>>> from gmail.com to something which allows to use mutt... ] >>>> >>>> Some releases after 5.17 bullhead rev 1.01 started to reset. >>>> I'm not sure which kernel version it started, because it might be >>>> caused by kernel config or dts changes. >> >> I propose to try to bisect it to specific commit in Linux kernel. > Hi Krzysztof, > > thanks for a suggestion, that's what I do for a non-embedded kernel (e.g. > x86_64, ppc64le, or even aarch64 used on server), because these works on > defconfig. But on qcom bullhead and angler devices, last few months I've come > across to few broken boots, although some of them were regressions others > depends a lot on particular config. And since last 2 or 3 kernel releases it > does not even boot on defconfig. It's quite frustrating to bisect with cross > compilation (takes time) to realize that it boots with custom config. Last time > it took a week and I tried to find what actually caused phone reset, > unsuccessfully. That's why I'm asking before wasting more time. > > Of course with no suggestion I there is no other option than to do > bisecting again. I understand that false positives/negatives due to config changes are frustrating, but what stops you from using all the time your custom config? I was bisecting on embedded devices many times and the only slow parts in my case was booting device over network and few builds (like 6 out of 12 steps, rest is fast due to ccache). There is basically no difference (except that booting over network) when bisecting on VM or my boards. Cross compilation does not take any more time than regular build, so maybe your setup could be improved? Best regards, Krzysztof
