QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
543 stars 48 forks source link

Screen blanking when using LibreOffice Calc #9112

Open emanruse opened 7 months ago

emanruse commented 7 months ago

Qubes OS release

4.2.1

Brief summary

Working in LibreOffice Calc results in irregular screen blanking.

Steps to reproduce

  1. Use fedora-38-xfce template, have libreoffice-calc and libreoffice-kf5 installed
  2. Edit a spreadsheet in LibreOffice Calc
  3. (Optional) open additional windows, right click on sheet tabs - just things which seem to result in faster appearance of the blanking. There is no exact reproducible pattern. The issue sometimes appears even when not doing anything - not even moving the mouse or pressing keys.

Watch journalctl -f in dom0.

Expected behavior

There should be now flaws.

Actual behavior

Very often (can't find exact pattern), the screen would blank for 2-3 seconds and restore itself. The journal always shows errors like:

...
[ 7245.803704] dom0 sudo[35223]: PAM unable to dlopen(/usr/lib64/security/pam_sss.so): /usr/lib64/security/pam_sss.so: cannot open shared object file: No such file or direc>
[ 7245.805286] dom0 sudo[35223]: PAM adding faulty module: /usr/lib64/security/pam_sss.so
...

Sometimes also:

[ 7234.702336] dom0 kernel: i915 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun

FWIW, there is enough free memory in the VM.

3hhh commented 7 months ago

Possibly related: #8281

emanruse commented 7 months ago

Perhaps rather #2399

emanruse commented 7 months ago

Additional observation:

This system uses 2 screens - one 4K and one 2K. The issue seems to appear while using using the 4K screen only. So far, I have not noticed it while using the 2K one only.

apparatius commented 7 months ago

Did you configure VRAM? https://www.qubes-os.org/doc/gui-configuration/

emanruse commented 7 months ago

@apparatius

Yes, I have done that long ago (see #7722). However, I am not sure whether it is the issue because:

  1. It seems to me the documentation is wrong. It says:

For example, if you expect to use a 1080p display and a 4k display side-by-side, that is (1920 + 3840) × 2160 × 4 / 1024 = 48600, or slightly more than 48 MiB per qube. After making these adjustments, the qubes need to be restarted.

IMO, the correct calculation (for 8-bit displays) is:

(3840 2160 + 1920 1080) * 4 / 1024 = 40500

Also, I don't quite understand the "per qube" phrase, and "the qubes need to be restarted". What does this mean? There is only one guivm - dom0.

"4" implies 4 bytes, i.e. 4 * 8 bits. The 4K display is 10 bit (1.25 bytes). (something which the documentation does not address), so the actual calculation for my case would probably be:

((3840 2160) 1.25 + ( 1920 1080 )) 4 / 1024 = 48600

IOW, the number now matches the doc for the specific case (a coincidence) but the formula is different.

  1. In any case, looking for a workaround of #7722, at that time I have set it to 81000. Perhaps way too much but I left it like that. Also, I have not touched gui-videoram-overhead. There is plenty of available RAM in the domU running LibreOffice and in dom0.

I am mentioning this not just as a reply to your question but also just in case that may be a signal for something else causing the current issue.

apparatius commented 7 months ago

IMO, the correct calculation (for 8-bit displays) is: (3840 2160 + 1920 1080) * 4 / 1024 = 40500

I guess it's not handling it as two separate rectangles but as a single rectangle with a width = display1_width + display2_width and height = max(display1_height, display2_height).

Also, I don't quite understand the "per qube" phrase, and "the qubes need to be restarted". What does this mean? There is only one guivm - dom0.

The gui-videoram-min/gui-videoram-overhead features are passed from dom0 to the qubes using QubesDB and specified VRAM is allocated inside the qube. The Qubes GUI agent is handling this inside qube. And since the gui-videoram-min/gui-videoram-overhead feature are read and applied inside qube during qube start then for new gui-videoram-min/gui-videoram-overhead values to take effect you need to restart the qube.

emanruse commented 7 months ago

The gui-videoram-min/gui-videoram-overhead features are passed from dom0 to the qubes using QubesDB and specified VRAM is allocated inside the qube. The Qubes GUI agent is handling this inside qube.

Thanks for explaining.

I guess it's not handling it as two separate rectangles but as a single rectangle with a width = display1_width + display2_width and height = max(display1_height, display2_height).

I suppose you may be right (and I will reconfigure assuming you are). But what about bit depth?

apparatius commented 7 months ago

I suppose you may be right (and I will reconfigure assuming you are). But what about bit depth?

I'd assume that maximum bit depth would be used if it's handled as a single uniform rectangle.

emanruse commented 7 months ago

OK then. I will re-configure this and keep watching it.

emanruse commented 7 months ago

It keeps happening with gui-videoram-min set to 97200 (as per the instructions given in the docs) and after rebooting too.

marmarek commented 7 months ago

Check dom0 dmesg for a message like this:

i915 0000:00:02.0: [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.

if you have it, follow the advice

emanruse commented 7 months ago

After booting, I don't see such message in journal (I do see the PAM error though). I will check again when the issue re-appears but this system uses coreboot and I don't see any "stolen memory size", so probably not possible to follow the advice anyway.

BTW, yesterday it appeared even after quitting LibreOffice (1-2 seconds right after it).

emanruse commented 7 months ago

Ever since setting (without typo) the gui-videoram-min using the correct formula and rebooting, I have been experienced another (additional) issue: After the system has been screenlocked for e.g. an hour, I type the password to unlock it and after pressing Enter the screen becomes blank (ON but blank) and nothing seems to be able to restore it. It happens only sometimes.

I switch to a text console, where I am able to login and look at the journal - the additional error mentioned by Marek is not there (and I don't think I have ever seen it at all) but the PAM error is.

During the whole boot session I have not even started LibreOffice.

emanruse commented 7 months ago

Just happened a few after a system reboot without even starting LibreOffice or the qube I usually run it in.

Same PAM error in journal (twice), preceded by the FIFO underrun error too (5 seconds before it in the log).

I was playing with the new qui-devices menu when this happened.