https://bugzilla.kernel.org/show_bug.cgi?id=203317 --- Comment #8 from howaboutsynergy (howaboutsynergy@xxxxx) --- But, I 've already tested that reverting that commit gets rid of the freeze. Even if the cause is somewhere else, it appears that the regression is introduced by the very commit I mentioned: aa56a292ce623734ddd30f52d73f527d1f3529b5 (and that commit mentions this issue - which is why I'm posting here) I mean, the only thing I could try to do is to somehow find a way to get a stacktrace while the system is frozen, but for some reason even manually causing kernel to crash(sysrq+c) fails to allow me to read the dump via 'crash' afterwards ... Also, I've encountered the freeze during chromium compilation (possibly because it uses at least 15+GiB of 32G of RAM due to jumbo). Even though it's easier for me to trigger the freeze via the 'memfreeze' script. So I expect users will hit this soon. (assuming they use some kind of ext4, I use it on the /tmp and /var/tmp zram) Not sure how else to say it. I used bisect to find the commit(a while ago), tested with and without it. Ahh forgot to mention that what I said in Comment 6 (that freeze/race) happens when the commit is NOT reverted. But this isn't the same freeze that happens during the memory pressure which simply does a ton of disk reading. I know because I'm already patching against it by keeping Active(file) above 300MiB. (see Comment 4) I'm happy to try other things to help with this. Please let me know what I could do. -- You are receiving this mail because: You are watching the assignee of the bug.
