Qubes is EXTREMELY slow on very new p1 gen 5 lenovo laptop

After fixing my previous problem here by using the code in the troubleshooting section:

Using qubes is extremely slow. It is almost as if the display is updated once every 4 seconds or so - making for about 0.25 FPS display!

Is this because of the solution described here that I used during installation?:

Even my old laptop that runs qubes uses the integrated graphics is not anything like this.

What’s the CPU model with what generation?

Maybe its a CPU frequency scaling bug.

12th gen i7-12800H , thanks for your reply.

Just had a look at that… looks very complicated. Wouldn’t know where to start :confused:

It seems that pre-loading of qubes (where I enter the initial encrypted password) is fast, and the screen updates with the password/loading bar very quickly.

You may need to install kernel-latest, switch governor to performance as said here:

Look like the scaling problem of Alder Lake has been discussed here:

1 Like

That’s it, either your i915 driver isn’t functioning right ( because the luks password stage is CPU drawing graphics), or your CPU somehow slowed down when logged in. You can first run xenpm get-cpufreq-para and xenpm get-cpufreq-states in a terminal to see if all your cores are running full-speed. If so, then it’s your intergrated GPU driver that is causing the problem.

I just ran that (it is very hard to use when the screen updates so infrequently and got this):

the cpuids go from 0 (400mhz) ,2, (2400mhz), 4 (400 mhz), 6 (400 mhz), 8 (400 mhz), 10 (400 mhz), 12 (400 mhz), 13 (400 mhz), 14 (400 mhz), 15 (400 mhz), 17 (400 mhz), 18 (400 mhz), 19 (400 mhz),

so some cpuids appear to be missing (? Maybe ?), but all but one cpu appear to be running at 400mhz. However…

I set the governor to performance, and min-freq to 1500000 but its still laggy. Rerunning xenpm get-cpufreq-states shows all the cpus at 2400mhz.

I thought I disabled the nvidia gpu (or something like that) when installing qubes with the troubleshooting mentioned in the first post?

I guess the next step is to try with kernel latest? Is there a more up to date kernel than 5.17.5 ? If so where do I find it?

I really appreciate you helping me with my noobiness mate

You can first enable testing repo in qubes-manager global settings, then sudo qubes-dom0-update kernel-latest to get kernel-latest. It’s 5.19.9, newer than 5.17.

It seems that your E-cores are running at a low frequency. I’ve read that Xen currently only partial supports big.LITTLE arch. You have to manually create CPU pools to distinguish between P and E cores, to avoid your workflow being switched onto E-cores.

This is a problem because the networking doesn’t appear to be working lol!

Can I download qubes with 5.19.9 anywhere, before I go trying to configure an adapter at 0.25 frames per second? I would rather just reinstall than do that probably.

Do you think it has anything to do with the install parameters I used?

 nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off

There is the option to use this, but I used the above one and the install worked.

 noexitboot=1 modprobe.blacklist=nouveau rd.driver.blacklist=nouveau --- intitrd.img

There’s definitely something wrong about your CPU frequency driver. You should be able to boost to P1 state, to have turbo freq and much higher freq than 2.4G. There’s one option to let dom0 kernel to handle CPU scaling, although there’s limitations. You can try to add cpufreq=dom0-kernel to your grub conf file, to Xen options part.

There’s openQA builds at here, but the iso isn’t signed, so the integrity cannot be assured.

1 Like

Okay, I’m unsure even how to access the grub conf file, I have to go now. I’ll have a look later. Thanks for all your help!

I think I will try to install with the latest kernel, try the fixes mentioned in the threads above as well as yours with the grub conf file. If I manage to fix it like that I will revert back to the verified iso, install the latest kernel and repeat.

Just as a side note the screen just went to the lock-screen where I have to re-enter the password and the bar and password were refreshing fast - like if everything was working normally… no idea what that means…

In fact, long time ago on debian, I had extremely laggy graphics without nouveau. In that your CPU frequency is higher now, you should at least be able to see smooth cursor movement. But that’s not the case.

Your installation grub options don’t influence the default install’s grub options. If you enter edit mode during grub, you might find that there’s no blacklist=nouveau or so. If it’s a problem for installation, it might also be a problem for post-install running. So why not try to add those options to grub and see if this works?

I see, didn’t know that. During installation however it was extremely laggy, just like now. nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off
was used just to get to the installation screen - it said pane is dead etc if I didn’t add that.

So if it was laggy during installation maybe it’s not that? - I’ll give it a go if the updated kernel and the cpufreq=dom0-kernel don’t work.


Has Intel really changed their CPU much if any? I might be wrong but all they’ve really done in increased performance, aside from GPU, so maybe the CPU isn’t the problem. For me, I’ve found the motherboard is a hodgepodge of various hardware from numerous vendors. If there’s a compatibility problem, I’d lean there.

I have the X1 extreme gen 5 which is considered to be the “sibling” of the P5. I had the same problem and put trouble shooting steps in my HCL report. Check out the “Integrated GPU Screen Tearing” section.

I would also check the display setting in the bios. There might be an option to increase the integrated gpu memory. I increased mine to 512MB which helped a lot!

Report: Thinkpad X1 Extreme Gen 5

1 Like

Now we are getting somewhere!

I followed your steps - the config file didn’t seem to do anything but I wasn’t having screen tearing, just extremely slow refreshes of the screen.

Removing the Nouveau disable in the grub from installation and setting the GPU to dGPU fixed it though and now I am running buttery smooth!

I cannot change the resolution without it bugging out, or change the hz… but at least it’s working! I can fix scaling problems later - however if you know how to fix this that would be a bonus!

Does the Wi-Fi work in the latest kernel then? My WiFi isn’t working, thus I have no way to safely update to the latest kernel haha! I’m thinking I’ll buy a Alfa AWUS036ACH adapter as they are supposed to work out the box and update the kernel.

Thanks again, and please let me know about the above when you have a minute!

Glad to hear that! Switching to the discrete GPU allowed me to change my resolution and refresh rate. It might be that your GPU is not completely supported by Nouveau. If that’s the case, you’ll just have to be patient and wait. I don’t think you can install Nvidia drivers in dom0 anymore. You can check Nouveau’s codename and feature matrix. I’ll leave the links below!

The wifi works with the latest stable kernel. Just update your sys-net template and give it a restart. I would also try updating dom0 and see if that fixes anything

Nouveau Code Names: CodeNames
Nouveau Feature Matrix: FeatureMatrix