mikhail wrote: > On Fri, 2017-12-08 at 19:18 +0900, Tetsuo Handa wrote: > > Most likely cause is that I/O was getting very slow due to memory > > pressure. > > Running memory consuming processes (e.g. web browsers) and file > > writing > > processes might generate stresses like this report. > > > > I can't tell whether this report is a real deadlock/lockup or just a > > slowdown, > > for currently we don't have means for checking whether memory > > allocation was > > making progress or not. > > It not just slowdown because after 5 hours I was still unable launch > even htop. After executing command was nothing happens. I was even > surprised that dmesg could work. Then, it seems that it was a real deadlock/lockup. > > Thanks for the advice. > Decided to check what happens when I do SysRq-t. > SysRq-t produce a lot of the output even without running Google Chrome. > Such amout of data does not fit in the kernel output buffer and it's > impossible to read from the screen. > > Demonstration: https://youtu.be/DUWB1WGBog0 Under OOM lockup situation, kernel messages can unlikely be saved to syslog files, for writing to files involves memory allocation. Can you set up netconsole or serial console explained at http://events.linuxfoundation.org/sites/events/files/slides/LCJ2014-en_0.pdf ? If neither console is possible, it would become difficult to debug. Michal, any idea? -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
