https://bugzilla.kernel.org/show_bug.cgi?id=201685 --- Comment #221 from Rainer Fiebig (jrf@xxxxxxxxxxx) --- #218 If 4.18.20 turns out to be OK, my idea would be to bisect between 4.18 and 4.19. Jimmy.Jazz has already done that and the result pointed to RCU. But IIRC it was not a clear cut > git bisect bad xyz123 is the first bad commit With your script we now have a tool to reproduce the problem which makes the distinction between "good" and "bad" more reliable. And everybody is now also aware how important it is to ensure that the fs is OK after a bad kernel has run and that the next step should be done with a known-good kernel. So it should be possible to identify a bad commit. Perhaps one could limit the bisect to kernel/rcu or block in a first step. And if that's inconclusive, extent the search. But if 4.18.20 is bad, I have no clue at all - at least at the moment. -- You are receiving this mail because: You are watching the assignee of the bug.