Linux 5.19 issue with CPU capabilities

B

brad-x

Junior Member
A Linux VM booted with kernel 5.19 posts an early error to the kernel ring buffer related to XSAVE - there have been recent changes to the way the kernel will call for CPU capabilities (asking for XSAVEC when in a VM on Sky Lake and later Intel CPU's per https://www.phoronix.com/news/Linux-5.19-XSAVEC-Support)

The VM will then boot but will be missing detected CPU capabilities like AVX and PCLMUL causing seemingly random userland errors from the perspective of the user.

I will be able to follow up with a dmesg snippet a bit later today. This was tested with Fedora and Gentoo Linux.
 
It's the case on Manjaro and Kali with 519. The difference is that Gnome on 519 Arch refused to start, I wonder if any other distributions have the same problem.

journalctl:
systemd[750]: Failed to start Application launched by gnome-session-binary.
systemd-coredump[1294]: [] Process 807 (gnome-shell) of user 1000 dumped core.
 
full dumped core:
Module linux-vdso.so.1 with build-id 0b50b426a9c09c7a3dcbd9ef2237f69a3a99a80f
Module p11-kit-trust.so with build-id 8b539aa1d5ee1ffc32e4c6f71c132e40e09ffbb7
Module libgmp.so.10 with build-id 26cec2ebe94cc5c4cb99e6988717347222b324fd
Module libhogweed.so.6 with build-id 5c4a99ad0aabe13bd9b517f92ab339436a2bc1f2
Module libnettle.so.8 with build-id 6a26cbe6819abc8c57668f80ca8c8160fd85e29e
Module libtasn1.so.6 with build-id ee3429ca5e94718aea4fe5249fc859e0cd88e4e9
Module libbrotlienc.so.1 with build-id 74adbc62e4fbb5da9d37b5aa458471f4130862ff
Module libgnutls.so.30 with build-id 816201e11cc13561e1272b96a1c7cdb97ae59997
Module libgiognutls.so with build-id 339b7ddbb749ada73d55c9e86d19a94ea38bc1d6
Module libgiognomeproxy.so with build-id 0e9b3cc0fce9ff4a7461da6874a887a2801c57a8
Module libgioremote-volume-monitor.so with build-id 09e0401064967de32a6cf3a0da0b371da>
Module libcrypt.so.2 with build-id a0a45f81771945f0559d04e93726d245159930da
Module libaccountsservice.so.0 with build-id b5d787504386723b96e65022ca1ed2e9c4a285a2
Module libopus.so.0 with build-id 35fafc4024675e9cfe57c7d50c3965eac6bac358
Module libFLAC.so.8 with build-id 3637a78858507a848ee0a48c50902c943e5bc58f
Module libvorbisenc.so.2 with build-id 2b1ce7fcdcc925bc663ebe2c1c008c0dd96e5bd0
Module libasyncns.so.0 with build-id 3ed7e52f247b08f1dff19aef6a253ee4c5c785c0
Module libsndfile.so.1 with build-id 407b2376cac1726631e3f7360a9337901be04ec0
Module libpulsecommon-16.1.so with build-id 17e5c781f557e60fbc789cb631816a4a29230f4a
Module libpulse-mainloop-glib.so.0 with build-id 557c18bd5f54743e924a5b8e77bbc1b55a31>
Module libpulse.so.0 with build-id 0c1618cb1e11cc14128914e45965433374cbd10e
Module libgvc.so with build-id 98f8b60a48f3c180a6c72eb761afc21a624da9e0
Module libupower-glib.so.3 with build-id 7303cc5649cb941e05197c70b6863dae83840e5f
Module libgnome-bluetooth-3.0.so.13 with build-id 0910ae040cf33126ade2919b741c4a1569a>
Module libgeocode-glib.so.0 with build-id 0d70e908e990d5cb0ea7a3d599db7fd0dd34ded7
Module libgweather-4.so.0 with build-id 2b4819a76ee3b7beffd9d50b9383f91a05dcc432
Module librsvg-2.so.2 with build-id 1cb5dfb747cdb53ba90f504acbe23de518c29ad9
Module libpixbufloader-svg.so with build-id b496e4f240c3dd862a5fe9ad31a464e65692cc08
Module libgdm.so.1 with build-id 5ec9d3daf2f88e4ecfb7954881b4dbd216c2961c
Module libgeoclue-2.so.0 with build-id c4fbb36d5d77c684c563056dd5a075772a0463dc
Module libmalcontent-0.so.0 with build-id 6b0f4053aeaf370d846874b64f1daeab457dea89
Module libibus-1.0.so.5 with build-id 9ee6cfbac64630c1ecf356c6f72d46f932e20be8
Module libresolv.so.2 with build-id 5c4d9f10ee9ce5e768e5b910e6b430f352a7aae1
Module libkeyutils.so.1 with build-id ac405ddd17be10ce538da3211415ee50c8f8df79
Module libkrb5support.so.0 with build-id 15f223925ef59dee4379ebbc0fcd14eda9ba81a2
Module libcom_err.so.2 with build-id 3360a28740ffbbd5a5c0c21d09072445908707e5
Module libk5crypto.so.3 with build-id cc77a742cb62447a53d98285b41558b8acd92866
 
I started seeing this today on Fedora 36. Unfortunately, the 5.19 upgrade coincided with a Parallels 18 update ... Having said that, moving back to 5.18 and all is stable.
 
I just got bit by this today (Parallels Desktop 18 on macOS Ventura on a 2018 T2-based MBP) on Debian/bookworm (testing). libgnutls uses AVX functions, which means now that anything that uses HTTPS (git, aria2c, curl, etc) instantly crashes with an illegal instruction trap (SIGILL). VMware Fusion 12 and VBox 7 both don't seem to have this issue. This should be a high priority blocker for Parallels!
 
DustinM2 said:
I just got bit by this today (Parallels Desktop 18 on macOS Ventura on a 2018 T2-based MBP) on Debian/bookworm (testing). libgnutls uses AVX functions, which means now that anything that uses HTTPS (git, aria2c, curl, etc) instantly crashes with an illegal instruction trap (SIGILL). VMware Fusion 12 and VBox 7 both don't seem to have this issue. This should be a high priority blocker for Parallels!
Click to expand...
Yeah - A partial workaround for me on Fedora36 was to downgrade libgnutls, but there were many other things crashing still, so I just kept with 5.18
 
I suggest everyone affected should raise a ticket, otherwise there is little chance the issue is ever going to be addressed. :(. Over the last few months I am observing steady degradation of my VM's graphics -- I am having so many messed up artefacts when screen renders that it is almost impossible to work in a VM. Moreover, anything that is Chrome based just started to crash with a segmentation faults. I am not sure that I want to renew my subscription in a couple of months time, to be honest.
 
Just got done setting up a Lenovo Legion 5i Pro Gen 7, which is going to offload my Intel-based Win11 and Linux VMs in a dual-boot. Going to suck going back to two boxes, but at least the Lenovo has the power to play games like Arkham Knight, which the VM didn't. Have used Parallels for 15 years. End of an era.
 
It would be so nice if somebody from Parallels Inc could acknowledge the issue and comment whether they are going to fix it or not. We would gladly tag @parallels if we knew the handle we should use for bringing a topic to engineers' attention.
 
Hello!
Thank you for bringing it up. The issue has already been escalated to our R & D Team, they're working on the fix.
As a workaround, we advise you to perform the steps below:
1. Shut down the virtual machine (Actions > Shut down).
2. Open its preferences as per https://kb.parallels.com/117287 > Hardware > Boot Order > Advanced Settings.
3. Paste the following system flag:

kernel.xsavec=0

4. Check if the issue still persists. If it does, kindly collect a fresh technical report (click on the Parallels icon > Help > Send technical data > Send report) and send it to us in your reply.
 
@Mikhail Ushakov, thank you. This system flag has helped at least with my situation (all binaries that were crashing before are now working!). Will wait for the correct resolution of the issue in Parallels Desktop, but for now at least we have a workaround.
 
@Mikhall After this fix, I can install Ubuntu 22.04 fine, but installing Parallel tools into that Ubuntu 22.04 VM still fails (compile error). Is there a fix for that as well? Has it been fixed in Parallels 18?
 
@BrunoR8, please do not hijack threads -- it makes it hard for people to search for solutions. Your issue is not related to CPU capabilities at all, please create your own thread. Thanks!
 
You must log in or register to reply here.
Back
Top