On 6/16/19 12:12 PM, Mikhail Gavrilov wrote: > Hi, > I finished today bisecting kernel. > And first bad commit for me was cd736d8b67fb22a85a68c1ee8020eb0d660615ec That's commit "tcp: fix retrans timestamp on passive Fast Open" which is almost certainly not the culprit. > Can you look into this? > > > $ git bisect log > git bisect start > # good: [a188339ca5a396acc588e5851ed7e19f66b0ebd9] Linux 5.2-rc1 > git bisect good a188339ca5a396acc588e5851ed7e19f66b0ebd9 > # good: [a188339ca5a396acc588e5851ed7e19f66b0ebd9] Linux 5.2-rc1 > git bisect good a188339ca5a396acc588e5851ed7e19f66b0ebd9 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 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.
