Re: Google Chrome cause locks held in system (kernel 4.15 rc2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux