On Mon, 17 Jun 2019 at 17:17, Vlastimil Babka <vbabka@xxxxxxx> wrote: > > That's commit "tcp: fix retrans timestamp on passive Fast Open" which is > almost certainly not the culprit. Yes, I seen also content of this commit. And it looks like madness. But I can proving that my bisect are properly created. Here I saved all dmesg output from all bisecting steps: https://mega.nz/#F!00wFHACA!nmaLgkkbrlt46DteERjl7Q And only one of them ended without crash message "kernel BUG at mm/swap_state.c:170!" This is step5 with commit 3d21b6525cae. I tried to cause kernel panic several times when kenel compiled from commit 3d21b6525cae would be launched and all my attempts was be unsuccessful. So I can say that commit 3d21b6525cae is enough stable for me and I now sitting on it. > You told bisect that 5.2-rc1 is good, but it probably isn't. > What you probably need to do is: > git bisect good v5.1 > git bisect bad v5.2-rc2 > > The presence of the other ext4 bug complicates the bisect, however. > According to tytso in the thread you linked, it should be fixed by > commit 0a944e8a6c66, while the bug was introduced by commit > 345c0dbf3a30. So in each step of bisect, before building the kernel, you > should cherry-pick the fix if the bug is there: > > git merge-base --is-ancestor 345c0dbf3a30 HEAD && git cherry-pick 0a944e8a6c66 Oh, thanks for advise. But I am used another solution. (I applied the patch every time when bisect move to new step) > Also in case you see a completely different problem in some bisect step, try > 'git bisect skip' instead of guessing if it's good or bad. > Hopefully that will lead to a better result. If you take a look all my dmesg logs you can sure that all bad steps ended with crash "kernel BUG at mm/swap_state.c:170!". And yes, I look again at commit cd736d8b67fb still don't understand how it can broke my system. -- Best Regards, Mike Gavrilov.
