"Xorg invoked oom-killer" while resizing terminal windows


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.


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


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.


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


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?


i started this thread a while ago, something similar?

It looks similar but in your case increasing VM’s RAM fixes the issue. In my case it does not.

OOC, is it normal such major issue to get so little attention here and zero attention on GitHub?

I am just trying to understand whether it is me asking/reporting the wrong way, or is it something already well known to most people, thus others knowing of some useful workarounds, or something else?

Sorry for bothering, it is just too problematic to see windows crashing like that.

imo it isn’t a major issue.
There’s a simple workround - Don’t repeatedly resize windows in this way.

It isn’t restricted to 4k display - it’s repeatable on even basic
And it’s undoubtedly a symptom of a bug, but it isn’t a major issue - if
it affected many people in normal use it would be a major issue.
I see an issue raised on GitHub.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

It happens even without repeatedly resizing windows. I have seen it even if I resize a window only 2 times in a short time, e.g. if I had tiled the window left instead of right and correcting myself. I also saw it happening while a very short panel widget of sys-net was running in its own small window and simply a terminal window of sys-net was opened, while I was setting some properties of that panel.

Isn’t it major that it is so easy to trigger a (false) OOM error when there are tons of RAM available, resulting in such significant UI issue?

Well this is quite a different report.
And what you are reporting now does not happen for me on a standard
display - perhaps the 4k display has a hand in this.
You’ll need to provide more information about the drivers and hardware.

Well this is quite a different report.

What makes it different? In my initial message here I mentioned:

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

In case it is not understood so far, this happens even on a freshly booted Qubes OS, i.e. with only the default (as in default installation) qubes started automatically.

Should I add something to the bug report?

And what you are reporting now does not happen for me on a standard
display - perhaps the 4k display has a hand in this.

It happens to me even when the 4K display is used in 2K (1920x1080) resolution. Doesn’t that exclude the resolution as a factor?

You’ll need to provide more information about the drivers and hardware.

The hardware is a NitroPC with a 4K 10-bit screen connected via DisplayPort.

I also tested with a 8-bit 2K screen connected via HDMI. The result is inconsistent when I start the default terminal emulator/command line for the respective qube:

  • Disposable: fedora-36-dvm: no issue
  • Disposable: whonix-ws-16-dvm: no issue
  • sys-firewall: no issue
  • sys-net: crashes
  • sys-usb: crashes
  • fedora-36: freezes after holding the keyboard shortcut long enough and the interface inside the terminal window becomes unresponsive. It cannot even be closed normally, so one needs to restart the qube to restore normal functionality.

What should I do?

I still hope for some help with this.