Stuart Henderson: > On 2017/12/06 20:54, Anonymous wrote: >> Stuart Henderson: >>> On 2017/12/06 03:47, Anonymous wrote: >>>> The freezes can be short - a few seconds - or longer, about a minute >>>> long. This often happens when I launch or quit mpv, these freezes are >>>> typically long. I'm working on a small GLFW+OpenGL program, at this >>>> point it basically creates a window, does some other stuff and quits. So >>>> a window is quickly created and destroyed - that also causes freezes, >>>> typically short ones. Once the system froze while I was downloading a >>>> file. The LED indicating disk activity kept flashing as well as the LEDs >>>> in the Ethernet port. During a long freeze the fans spin faster judging >>>> by the noise. Overall the graphical side feels more sluggish that in >>>> 6.1, I don't use the console for anything but logging in and starting X. >>>> >>>> In 'messages' (a copy of /var/log/messages) look for 'Resetting chip >>>> after gpu hang' as well as the error messages at the start. >>> >>> There's not a lot of RAM. Is the system swapping? >> >> No. top gives me: >> >> load averages: 0.06, 0.11, 0.06 localhost 20:41:54 >> 65 processes: 64 idle, 1 on processor up 1 day, 6:48 >> CPU0 states: 2.1% user, 0.0% nice, 0.8% system, 0.3% interrupt, >> 96.8% idle >> CPU1 states: 2.4% user, 0.0% nice, 1.2% system, 0.0% interrupt, >> 96.4% idle >> Memory: Real: 409M/1015M act/tot Free: 918M Cache: 322M Swap: 0K/2055M >> >> and that's a common picture. I ran top right after a couple of freezes >> and got a similar output. I use i3, lxterminal, and vim/neovim for most >> of my work and I'm writing this in Thunderbird. Also in that situation >> when I was downloading a file I was using a cli program so it looks like >> only X was affected by the freeze. >> > > Thanks, that was one possible cause and easy enough to check. I have > run into similar problems myself (usually worse when certain processes > exited, chromium was the big one, mpv was fairly bad too), though > I haven't hit it recently. > > Not sure what else to suggest but if you can catch top -S output while > it's hitting the problem (just before/after?) it might give some clues, > especially the WAIT column.
I'll try to rig something. Any ideas better than just running top -S in a loop and saving output to disk? Like some test harness you developers use? Also, yes, big processes like TorBrowser, both starting and exiting (especially exiting) can trigger this for me and these freezes are long. I vaguely remember having this issue in a milder form in 6.1 (probably 2-3 times) or maybe even 6.0 (the first version I ever used) so there's a chance it's related to the general push to get rid of global locks.
