<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Xorg unresponsive under heavy system-load" href="https://bugs.freedesktop.org/show_bug.cgi?id=90492#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Xorg unresponsive under heavy system-load" href="https://bugs.freedesktop.org/show_bug.cgi?id=90492">bug 90492</a> from <a class="email" href="mailto:alexander.maznev@gmail.com" title="alexander.maznev@gmail.com">alexander.maznev@gmail.com</a> <pre>(In reply to Chris Wilson from <a href="show_bug.cgi?id=90492#c1">comment #1</a>) > You ran out of memory (including swap). The kernel cannot execute the GPU > commands due to memory exhaustion and that eventually lands in an untrapped > SIGBUS. The segfault is a bug elsewhere in the xserver. It is unresponsive > due to the amount of swap thrashing... > > For example, the first Xorg.0.log, the crash is due to not being able to > page in a library from disk. The second didn't have enough memory even to do > symbol lookups in the backtrace. The third is a segfault during client > shutdown, but it is not clear where. The last one is the only one that looks > like the ddx should have prevented but didn't (the ddx is aware that > accessing a mmap() may cause a SIGBUS due to oom and tries to trap them) -- > however, symbol lookup failed. So for what it is worth, I added a few > missing traps around pixman_fill based on the Xorg.0.log you reported on irc: > > commit 335ac8742e9eadcdf8f087b24f84c7df0fda31c0 > Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>> > Date: Sun May 17 08:53:45 2015 +0100 > > sna: Wrap CPU access for composite operations with sigtrap Hello Chris, Thank you for looking at this. I suspect in some-cases it's not running out of Memory at least directly (when I run with 1GB swap, opening this page with the firefox fills about 400mgb of the swap [so it's possible to load 3-4 before experiencing problems], if I turn swapoff, with 3gb RAM free the system becomes completely unresponsive just after one page load). vmstat shows a lot of inactive memory which is not being freed when the system runs low on resources? Further why isn't oom_killer handling this gracefully? Firefox has a +100 oomscore over any other running process when this is triggered and terminating it should return the system to a normal state.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>