On Sun, 2 Oct 2022 at 09:51, Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> wrote: > > 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? Thank you for pointing out ccache, I'm using it as well. Well, last time I wanted to speedup, thus I used custom config (with make oldconfig) in the middle of bisecting.which was a mistake (obviously it's important to keep the same config), which in the end took more time than compiling with the defconfig. The reason for not using defconfig was first speedup (disabled unused soc etc). Other time I found that problematic commit is a merge commit where both children are merges, which means to test all commits of one merge on the top of the other merge only to find that it's some kconfig option, but which? My frustration was also that already working things are broken (probably due wrong dts, which nobody found), but that's life (testing depends on the users of particular hw). OK, lesson learned + I need more patience :). (I've done several bisecting, but not for embedded, bisecting for some kernel non-drive subsystem is way easier, one can concentrate on the development). Kind regards, Petr > > > Best regards, > Krzysztof >
