On 2019-12-29 23:32, tetrahedra via qubes-users wrote:
On Sun, Dec 29, 2019 at 01:44:28PM +0000, 'awokd' via qubes-users wrote:
tetrahedra via qubes-users:
On Fri, Dec 27, 2019 at 09:57:16AM +0100, tetrahedra via qubes-users
wrote:
Unfortunately I need to get work done so have to reboot to "just
make it
go away" but I am still interested in troubleshooting ideas (for
when it
happens next).
Investigate xl top more thoroughly. You can identify offending VMs with
it, and see if all your RAM is in use which triggers swapping to (slow)
disk.
My disk is a pretty fast SSD, and I did use xentop (`xl top` is just an
alias for xentop) and it didn't show anything unusual as far as I can
recall. Perusing the xentop man page doesn't show any potentially
relevant options except for `--full-name` and that option doesn't seem
to do anything. Pressing "B" (for "vBds") seems to list a number of
devices for each VM but none of them have any 2-digit unique identifying
number (as `iotop` seems to display).
I have had graphics slowdown issues in the past on two occasions that
acted like this, so here are some things to try:
1) Add the 'nopat' argument to the 'kernel opts:' boot command line.
> qvm-prefs <AppVM> -s kernelopts nopat
2) The second, I can not seem to locate that email exchange at the
moment, but it was a option on the graphics subsystem that needed to be
turned off. Something like backing store, but I'm sure that is not the
correct name for it. I'll keep looking for that one until I hear back if
#1 above fixed your problem or not.
Steve
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/61f368b2-9623-4177-99d2-7aa395c45fab%40jhuapl.edu.
