"Xorg invoked oom-killer" while resizing terminal windows

Hi,

On my Linux systems I like to have shortcuts for tiling and maximizing my windows. In Qubes OS I did the same. In XFCE Window Manager settings I set them like:

Tile window to the top: Super+Home
Tile window to the bottom: Super+End
Tile window to the left: Super+Left
Maximize window: Super+Up

However, I notice this buggy behavior in Qubes OS:

If I open a XFCE terminal (or xterm) of a qube (e.g. sys-net, sys-usb, sys-whonix) and resize it many times quickly (e.g. by pressing repeatedly or holding Super+Up) the window disappears after a few seconds and xterm (or XFCE terminal) cannot be run again unless the qube is rebooted. I notice a similar behavior in ‘personal’ qube too. In it though, the inside of the terminal window becomes unresponsive - I can still resize it, it does not crash, but I cannot do anything inside it (type, click on the menu). In dom0 I don’t experience this problem though.

In Qube Manager I checked the logs of the qubes in which I tested and I see out of memory messages. They are similar to those “Xorg invoked oom-killer” ones shown in:

I also attempted a workaround - I increased the memory of sys-net from the default 400MB to 1600MB but that didn’t fix the issue.

FWIW the system I am testing on has 64 GiB RAM and a 4K desktop.

For comparison:

On a very old laptop with 2 GiB of RAM running openSUSE and XFCE on a 2K screen there is no such issue. I can hold e.g. Super+Up forever and it does not cause problems.

How can this be fixed, please?

This smells like more grant tables issues.

B

What does this mean and what can I do?

Grants are a Xen mechanism for VMs (including dom0<->domU) to share memory or move data between each other.

With 4.1 much of the inter-VM data transfer, including the UI, is more dependent on grants than in the past.

I’ve seen a lot of Issues in the Qubes-issues Repository traced back to bugs in Xen and/or Qubes usage of grants post R4.0 Qubes release.

Some of these issues are still open in the tracker.

4K displays has long been a trigger.

That being said it could also have to do with video ram settings issues which would be a separate issue.

See here: GUI configuration | Qubes OS

B

Thanks for this info.

I understand these formulas are for 8-bit displays.

Can you tell me how to modify these formulas for the case of using 10 bit display?

For example, suppose a setup consisting of a 4K 10-bit display and a secondary unpluggable 8-bit 2K display.

@brendanhoar

Looking again at that guide you give I reread “By default, it is as much as needed for the current display and an additional full HD (FHD) display (1920×1080 8 bit/channel RGBA)”. Testing in 1920x1080 mode though I still experience the issue. I don’t know why, I can only speculate that it might be due to the 10-bit video signal between the computer and the monitor.

I hope you or someone else can answer my previous question, considering the clarification.

So, after searching for the answer (and not finding it anywhere on the web), I tried to figure it out for myself:

The documentation says:

“By default, it is as much as needed for the current display and an additional full HD (FHD) display (1920×1080 8 bit/channel RGBA).”

and gives the formula:

qvm-features dom0 gui-videoram-min $(($WIDTH * $HEIGHT * 4 / 1024))

I know that “A” in RGBA stands for alpha (transparency) but I have no idea how a video signal can be transparent. Anyway, I assumed that “4” in the formula stands for 4 bytes (8 bits for each of the RGBA channels). So, knowing that 10 is 25% more than 8, I simply added the multiplier 1.25 in the formula for a single 4K 10-bit screen:

(3840 * 2160 * 4 * 1.25) / 1024 = 40500

Then:

qvm-features dom0 gui-videoram-min 40500

and rebooted the computer in order to restart all qubes.

Result: the issue remains.

I even tried not to reboot the whole system, supposing that the change might have not persisted (I have no idea how to check) and repeated the command in dom0. Then I simply restarted sys-net (and the qubes which depend on it).

Result: the issue remains.

I hope someone can help.

As this is really annoying (and looks buggy) I even tried doubling gui-videoram-min and set it to 81000 (2*40500). Unfortunately, the issue remains. This doc doesn’t seem to solve the problem at all.

I wonder what others’ experience with this is and how it can be solved.

It’s been quite some time with no feedback.
Is it a because it is a difficult undocumented question? Or maybe I should file a bug report?