R4.2.1 intel integrated graphics broken, R4.1 and R4.2.0 rc are good

User Support
1

I tried R4.2.1 on my machine with intel tigerlake cpu and found that intel integrate gpu does not seem to be fully working - dragging any window will cause dom0 Xorg process to take away 100% cpu time.

I tested on my R4.1 environment with any kernel version (6.1 6.6 all of them are fine) and R4.2.0 rc environment (with a kernel of 6.1) that I installed in july 2023. Even R4.2.0 rc works however R4.2.1 does not

This documentation and many documentation seems to imply that I should not use fbdrv but rather intel driver but I found that both my R4.1 and R4.2.0 rc environment are fine with fbdrv driver. So it is not about name of the driver that are used

This documentation does not seem to apply to my case as it does not explain why R4.2.0 rc works but R4.2.1 does not.

I grep’ed EE and WW (error and warning) in /var/log/Xorg.0.log and compared R4.2.0rc and R4.2.1 and find no error and find one exactly same warning

(WW) Falling back to old probe method for fbdev

indicating that this seems to not be the problem.

The R4.2.0rc is installed on a usb stick so that system allows all usb to connect to dom0; R4.1 is standard install with a sys-usb though

Anyone encountering the same problem that intel integrated graphic driver get broken after some update during these months?

Also anyone can give some advice on what I can try out? (no heavy experiments plz because I am not in a position to do intense experiments involving bisect heavily of various packages and hack much with different versions of packages)

The problem is: I cannot find any trace about the incident in any log file (journal, xorg.0.log, what else?)

The journal contains many “Interrupt for port 123, but apparently not enabled” and linux kernel WARNING, so I may try out swapping xen version to older one as my next trial step.

Any idea is welcomed where I could possibly make wrong about, the qubes os installing process is not that stable and I have to hack a bit to fix something up to make the installation resume.

2

You can try in Qubes OS 4.2.1 the older kernel version that worked in Qubes OS 4.2.0.

3

I thought that using fbdrv means you didn’t get any hardware support, and all rendering was done on the CPU.

I have always had the same experience with the fbdrv driver, high CPU usage and moving windows lag.

4

The modesetting driver should be used by default.

5

driver problem and linux/xen is mostly ruled out as I tried kernel 6.1/6.6 xen 4.17.1/4.17.4 various combination

I found some important packages differences between a version known to be working and the currently choppy R4.2.1
the working environment has xorg-x11-server.Xorg 1.20.14-23 & xfwm4 4.16.1-3
my environment has xorg-x11-server.Xorg 1.20.14-26 & xfwm4 4.16.1-4

And. I am shocked to find out that when I killed xfwm4 process in dom0, dom0 window moves without any choppyness (qubes window cannot be moved, but dom0 xfce4-terminal can be moved by moving the title bar)

6

also killing xfce4-panel is working

Xorg takes 15GB virtual memory with xfce4-panel up, and 1.7GB virtual memory when it is closed. I am not sure which is wrong, Xorg, xfce4-panel, or xfwm4

7

Can you provide Xorg.0.log?

8

oops i just figured out what is wrong. I have set a background picture for xfce4-panel. When xfce4-panel have set a background picture, all gui actions are hooked and making the system extremely slow.

9

You’re certain you’re not using the intel driver?

I tried using this driver for a time instead of modesetting but I found it would cause memory spiking in the dom0 Xorg process and perceptible lag for some window manager actions. Rapidly switching among workspaces could cause Xorg to spike from ~5% of %MEM to >70% of %MEM as reported by top. With the modesetting driver it’s a pretty constant ~5% regardless of what I do.