HCL - Lenovo X1 Carbon gen 10

[Martin Holst Swende]

Hi,

I installed qubes on a brand new Lenovo X1 Carbon, but encountered a lot of issues.

1. The wifi is unavailable. I have no idea why, but I did boot it into an ubuntu live cd once, and the wifi card was found on ubuntu. This gist (https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112) contains the `lspci` and `lsusb` from both qubes and ubuntu.

On qubes, the relevant pci device is

00:14.3 Network controller: Intel Corporation Device 51f0 (rev 01)

On ubuntu, it is identified as:

00:14.3 Network controller: Intel Corporation Alder Lake-P PCH CNVi WiFi (rev 01)

2. Graphics is a mess. Already at the installer-stage, things were really bad. A drop-down window slide took on the order of seconds. I went through with the installation anyway, and the graphics are really really slow. Dropping down the upper-left menu takes ~1s, first showing a fragmented puzzle, and a bit later filling out the missing bits in the puzzle, and the menu is shown. I have a video, not sure if it's worth posting anywhere.

Fwiw,

- the bios does not contain any option to toggle between integrated / discrete graphics.

- I have not yet tested any of the tricks (i915.enable_psr2_sel_fetch=0) mentioned on https://forums.lenovo.com/t5/Fedora/Fedora-on-X1-Carbon-Gen-10/m-p/5135869?page=1.

[Martin Holst Swende]

Some follow-up. I tested also with a Fedora LiveCD, results are on the
gist
(here:https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-fedora-live-txt
) .

The Fedora livecd worked flawlessly, both wifi-wise and graphics-wise.
It was a fedora 36 -- whereas dom0 is still on Fedora32.

Is it in any way possible to try out some experimental repo where dom0
is more recent?


Cheers,

Martin Holst Swende

[Sven Semmler]

Thank you Martin for your HCL report. For now I filed it as works: 'no' ... let us know when this becomes a 'partial' with 'troubleshooting required'.

Your report is [online](https://www.qubes-os.org/hcl/#lenovo_thinkpad-x1-carbon-10-21cbcto1ww_i7-1270p_integrated-graphics-iris-xe_martin-holst-swende_r4-1) now.

/Sven

--
public key: https://www.svensemmler.org/2A632C537D744BC7.asc
fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

No, but I would like to know if your problems go away with
kernel-latest. If they do not, then this means that either Xen does not
interact well with Linux’s graphics drivers, or that the Mesa version is
too old for your hardware.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLzIakACgkQsoi1X/+c
IsHHLA//WlMdykRac3ryUTFwfm8sO3rRGGDyfNy8uIDoJ2DDRyEKqxbYFb6ZuZiS
xpxz07THDzEOIOqAQk8zJ+pj35P3R1mbkQw2J/q3xtVqxNrvI3kGVLX/MT5NM1a5
7YrjJ5cF8H279Vs2YtCR8TgmGi+RlnY1jYWWZ3p5oN5EYL96QLclj+2PEtur0Tpe
dR1kaFmRmBUnAz1/Mz9VCOn0LMWEJ0vWpDTuHcIIuSkgW4aXEyWwtyKiXwSmhUs/
feVNHeZOO8UUqlckk3e7cLnzQM8skWO4ZO0BdBZd2DNOtsFJMrx4opW00jDB0aKz
k7aLsTh7zl1+2Xx/mrMNXB5TgPhr9vt+ikWC3AK1THQ3DPF/LbT/CDxEI7SAZgBJ
fexcDFajFe2fFIVR1px20CTHtNGTj3UqX7TYFxFD3YAAB9z+KUvImNlypwxY5snK
ilNfxTLCrJYCPcatlYpDXXHAX/zm2UrhulbMfHSKPVDk4CCJSCQsv1q+0wtDCc4V
OR6vVJehDnPVcgy05lt1r9TIdCK9xZmjZBneyUNgBdP7gee9rc1owYxfOAzB4Fup
rXhloewao1p8ttizSw4FFPFJeWs+jHiNnygDuNbYxldnz6V6hFyZ4uQPIefjhDln
pBiQaEpQIcRaG0uy7XzF8VLLLfSgeNoLKPKYI3dOWCPFsSK6Hy8=
=Ux9E
-----END PGP SIGNATURE-----

[Martin Holst Swende]

On 8/10/22 05:10, Demi Marie Obenour wrote:
> On Tue, Aug 09, 2022 at 08:11:35PM +0200, Martin Holst Swende wrote:
> > Some follow-up. I tested also with a Fedora LiveCD, results are on
> the gist
> (here:https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-fedora-live-txt
> > ) .
>
> > The Fedora livecd worked flawlessly, both wifi-wise and
> graphics-wise. It
> > was a fedora 36 -- whereas dom0 is still on Fedora32.
>
> > Is it in any way possible to try out some experimental repo where
> dom0 is
> > more recent?
>
> No, but I would like to know if your problems go away with
> kernel-latest.  If they do not, then this means that either Xen does not
> interact well with Linux’s graphics drivers, or that the Mesa version is
> too old for your hardware.

Unfortunately, they do not. I did that as the first thing after getting
wifi to work, so the version 5.18.9-1 in the HCL, is kernel-latest.

Happy to try out any suggestion/experiment.

Cheers,

Martin

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

1. Does i915.enable_psr2_sel_fetch=0 help?
2. What X11 driver is Xorg using? If it is using Intel, does
modesetting help? If it is using modesetting, does Intel help?
3. Does HVM sys-gui-gpu work? What about PV (not PVH!) sys-gui-gpu?

If PV sys-gui-gpu with a dom0-provided kernel works, then the problem is
almost certainly old dom0 userspace: either an old X server, old Mesa,
or both. If you could build modern Mesa and/or X11 for dom0 and try
again, that would be awesome.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLz9W0ACgkQsoi1X/+c
IsGr+Q//UJPaZkdHsRSD3cGkhEA0A2faR6eKmJ8VFsVZalfp46ltQKszUrsb2zzo
nH8WsVelrODtPk46rRb177SrxOjaqbZZTQ0LZ5VooAghUfWWnYNPGepoCWqipUkd
oq4r43fIQUElxzA8bNbaPHBAFVoIwbdigL88+ZVcgysFGYdIegaYNcfWPaYVkMVd
mRDaTYgsVOlUMAdPC1KOAycRhB/DODhjnelUaeLVRcBAtNq2VrJHavvjku1gY0gK
7y4J5SI2Fm9YLsZpXBn5kMabUhgw/giqlWZ7p/IFXKPbzyVF+rab2Jji4l3oiqdy
k3kZfr3kCrcnoBivrk5P0EdwYzGZvs9GSoKXAKhRONAQ8ME8ELHq1B/HtZuVbclm
Ku0NkjNzLj/v89H+d3MNAxZdup5nsxsHdROm2m81Q2ivED9QuzY8WBEwVWkkTQPC
bC6AAir83/d9m4sk6tVbI4hVK/fBRbrpoE5rrFEIydxzPu3qvSTp1vlC7HMdvnle
4CzAHjvs20dI7J6RxfGFDI81OPb3REFvIItrS/0t448Vdg2Wjb2oJc8xlP4AZT1A
zbAcyuDG7FDOIlsdN2hkVV4SVXenPsen9utv8sn92P6HPl/zH4g7/F73HV9Ixy55
qUWXKKY4/m/ROYFaPkxewtD55062gmwRFK3kWz69gFoohohzJU8=
=j+83
-----END PGP SIGNATURE-----

[Martin Holst Swende]

> > Happy to try out any suggestion/experiment.
>
> 1. Does i915.enable_psr2_sel_fetch=0 help?

No, no change that I can see.

> 2. What X11 driver is Xorg using?  If it is using Intel, does
>    modesetting help?  If it is using modesetting, does Intel help?

More full logs/notes can be found at
https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-dom0_testing-txt
.

I'm not sure how to interpret the logs, it looks to me like "intel no,
modesetting yes". Not sure how/what to change here, given a nudge in the
right direction I can try to explore it more.

> 3. Does HVM sys-gui-gpu work?  What about PV (not PVH!) sys-gui-gpu?

I don't have a sys-gui-gpu at the moment, but will test that. This page
(https://www.qubes-os.org/doc/guivm-configuration/) is still the most
relevant/recent description, right?

>
> If PV sys-gui-gpu with a dom0-provided kernel works, then the problem is
> almost certainly old dom0 userspace: either an old X server, old Mesa,
> or both.  If you could build modern Mesa and/or X11 for dom0 and try
> again, that would be awesome.

Left for future reference, I'm taking baby steps here :)

Cheers

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Aug 11, 2022 at 09:07:22AM +0200, Martin Holst Swende wrote:
>
> > > Happy to try out any suggestion/experiment.
> >
> > 1. Does i915.enable_psr2_sel_fetch=0 help?
>
> No, no change that I can see.

Okay, so that is not the problem.

> > 2. What X11 driver is Xorg using?  If it is using Intel, does
> >    modesetting help?  If it is using modesetting, does Intel help?
>
>
> More full logs/notes can be found at https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-dom0_testing-txt
> .
>
> I'm not sure how to interpret the logs, it looks to me like "intel no,
> modesetting yes". Not sure how/what to change here, given a nudge in the
> right direction I can try to explore it more.

That is what it looks like to me also.

> > 3. Does HVM sys-gui-gpu work?  What about PV (not PVH!) sys-gui-gpu?
>
> I don't have a sys-gui-gpu at the moment, but will test that. This page
> (https://www.qubes-os.org/doc/guivm-configuration/) is still the most
> relevant/recent description, right?

I think so? I don’t use sys-gui-gpu myself, and I will admit that there
are quite a few bugs when using it. Still, if it works, then the
possible parts of the code that could be to blame is much lower. If
sys-gui-gpu in PV mode works, then the problem is almost certainly the
userspace drivers (Mesa). If sys-gui-gpu in HVM mode works, but it
fails in PV mode, then the problem is likely in the way i915 and Xen
interact.

> > If PV sys-gui-gpu with a dom0-provided kernel works, then the problem is
> > almost certainly old dom0 userspace: either an old X server, old Mesa,
> > or both.  If you could build modern Mesa and/or X11 for dom0 and try
> > again, that would be awesome.
>
> Left for future reference, I'm taking baby steps here :)

Valid :)

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmL0xOwACgkQsoi1X/+c
IsFd2w/+PURi2vrHaEzWaEJAS9mlUKM4gdel9oqaGuIWpOrFpNnjNSW4xuYy3HSB
j9fxftynuJgk36Fz3xza75mrGTY1HQ3ntkJmx/ABNB42YeAanElvo1ZZhLZbI4KD
8EU+EmFRTRlXZqxtvyQX3BqFDW3QTSY+dQLuNOYfe66/SfCYObWu1CeOjPT10Sdj
DtFzmzNV0vsF8bxRUGkrJRyNr6HdArRmS3a83PsaAA5KWN3vDasjNl80vBUfEJnN
yYPlVtZMdEdopAadPwXbiJ2/l9i2t6NFomm2XI8L4tHreW9BPvkf3BrAIRmnOKqw
Nwdvw8s0An9Dn1gdWJFtem9Mf8T+KYQ20aMJzTVbyamotV7vBQE+zPV5zCgjtzBP
FIZH/UOT1g3hftnzARUQ53CN7juwMAOLiFV+Nbg8IQeb4y1Anthu6qiJjJMMAkTL
mq3PNKqjWsBSk1in3C32RzUrBmSBEsuW0xw+ns/Dm5BnIuFn+0yOssbntMec/RK1
JA3HMVNpX0TY8RX85ZDH3ZoZz6RkjMxQLgJAbeQ5AkkFJgZ7xKACrphC3SAtgJgf
iW7v16IoCzwq2vnmWgEAGKYMp7zoeeOqS2DNAWrvPiHQl1CKllYBWvIIB1wWEiEM
VFJ0XfIgzr1OTRzoIos9vC5CkXyhuYm0v9HT5GWRTTgUszgvlbc=
=fOYw
-----END PGP SIGNATURE-----

[Martin Holst Swende]

I have tested this now. When I boot, the problem remains. Opening the
Qube Manager shows that the sys-gui-gpu qube is not running. I tried
starting it from the manager,
and it led to immediate black screen, requiring a hard shutdown. The
logs for that qube are here:

https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-guest-sys-gui-gpu-log


https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-guest-sys-gui-gpu-dm-log

I then switched it to PV mode. Same thing, does not startup +
blackscreen if I start it explicitly.

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

dom0 will kernel panic if the GPU is removed from it while in use. I
recommend preventing the i915 kernel module from being loaded in dom0
via the dom0 kernel command line.

- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmL0zgYACgkQsoi1X/+c
IsEB3w//V5thcPTmgEQhPwd4/8qSZWx3OqmvEiNDkH4Mj+Aw1mVICbMprqeyhUz0
8rlJK2sjPvZvF0xNRRuHedtdolliw/R5u0pQWoTtQ+CJd3hPJsoEXRja8lyPVYdS
UBvSNzPbsWZjCfE4uqEyHIhdEDmd53X/vvTikS9fu7x3+REdKTHd/tMR1yTB7bfw
chLg67/FFU1fgHVGQAkj3Hi2Rh8NF1uzG4VRLo0XFf0JG+M+SSb9L9MKijUkZWJZ
Qa9iuPn3wCrm9eNhWzskfatNnjh3PsYPVHH1f2X3bqH6TsGkpxbz2YyOVAp9PmDT
uvGUooDlouFfClKRPxtmkjqvnrquVbdzUgE6OdW023MgA6m5/eF8nHQYZLw3qcAz
apPwx9rjRKzRwE57saI+CFJGwuxlmD/8w9B+oWJ8bgXPcmEgmgM3rqsZrXgYM4uw
Ktq6tM1KZYbNN7naMEowPhvrMMbu2xx5OMxkQ9wZsU1HxFVY2zwAcOQttXblt5lj
VQEAUeysXvCffmrzhORqaUFuzBIX7iWoU5PCuCG2Pfb0YX9FeBhyaZlLLDA90R6m
yp4YWyNAZeq0Gfn3gZd2IVcYSdw+HjuWdYPTdhfhOA0wq5SxVt8MEtKe+ZelSSiw
bhZLV0PN+2ZLkIed5a0YM+FDnqIugLRNBMz50eeVzKAl8lInHyY=
=Gu+c
-----END PGP SIGNATURE-----

[Martin Holst Swende]

On 8/11/22 11:38, Demi Marie Obenour wrote:

3. Does HVM sys-gui-gpu work?  What about PV (not PVH!) sys-gui-gpu?

I don't have a sys-gui-gpu at the moment, but will test that. This page
(https://www.qubes-os.org/doc/guivm-configuration/) is still the most
relevant/recent description, right?

I think so?  I don’t use sys-gui-gpu myself, and I will admit that there
are quite a few bugs when using it.  Still, if it works, then the
possible parts of the code that could be to blame is much lower. If
sys-gui-gpu in PV mode works, then the problem is almost certainly the
userspace drivers (Mesa).  If sys-gui-gpu in HVM mode works, but it
fails in PV mode, then the problem is likely in the way i915 and Xen
interact.

I have tested this now. When I boot, the problem remains. Opening the Qube
Manager shows that the sys-gui-gpu qube is not running. I tried starting it
from the manager,
and it led to immediate black screen, requiring a hard shutdown. The logs
for that qube are here:

dom0 will kernel panic if the GPU is removed from it while in use.  I
recommend preventing the i915 kernel module from being loaded in dom0
via the dom0 kernel command line.

I've tried some variants now. Disabling i915 (by moving the driver flie) doesn't do much. It boots up as usual, same problems, and if I try to boot the sys-gui-gpu qube, it blackscreens and requires hard shutdown.

/Martin

[Martin Holst Swende]

New development: I used the boot param: module_blacklist=i915 (and the drivers were also removed from the filesystem).

This time, there were no graphics glitches. However, the sys-gui-gpu did not come up. I started a work -qube Firefox, thinking it maybe would kickstart the gui vm, but no. 

So maybe those gui-vm config steps do not fully enable it? I eventually (again) tried manually starting it, with the result of immediate blackscreen freeze. 

Not sure where that leaves me? I don't even know what the whole i915 thing is all about, what is it supposed to improve?

[Martin Holst Swende]

To follow up after a bit more experimentation.

- Using the boot param 'module_blacklist=i915' makes things work pretty
much ok. No obvious graphics glitches, it's able to play videos without
the fans spinning up like crazy.

- The PCI device for networking seems unsupported, so usb-wifi card is
needed to get networking working.

- I get no sounds. Pavucontrol lists "Dummy Output" as the only
available output device, so I guess the PCI device for sound is also not
supported. (My old laptop has "Built-in Audio Analog Stereo" output
device in pavucontrol).

- I did not get the whole sys-gui-gpu thing to work sufficiently to test
it, not sure if there's anything left to explore in that area. Mostly I
think a more recent kernel is the thing that will eventually solve this.

Cheers,

Martin

[Data Python]

You may want to keep your i915 driver and try: https://github.com/QubesOS/qubes-issues/issues/7507#issuecomment-1153081021

[Martin Holst Swende]

On Sun, Aug 28, 2022, 1:26 AM Data Python <big.data....@gmail.com> wrote:

You may want to keep your i915 driver and try: https://github.com/QubesOS/qubes-issues/issues/7507#issuecomment-1153081021

Interesting!

I tried it now, but unfortunately I encounter  a core dump, similar to one person in that issue. However, I don't think I have any spelling errors, and definitely no erroneous quote characters.

Cheers,

Martin

[Martin Holst Swende]

Well done!

How did you enable the 5.18 kernel? I've tried with 'qubes-dom0-unstable' and listing the available kernels, but it shows only a few versions of 5.15 as installation candidates.

Cheers,

Martin

On 9/20/22 05:36, Arran Lawley wrote:

Qubes is working for me on Lenovo X1 Carbon gen 10. 

To fix graphical glitches Dom0 needs to use kernel 5.18.16-1.fc32.qubes.x86_64 and create file with "sudo nano /etc/X11/xorg.conf.d/99-intel.conf" and add;

Section "OutputClass"

Identifier "intel"

MatchDriver "i915"

Driver "intel"

Option "AccelMethod" "sna"

Option "TearFree" "true"

Option "DRI" "3"

EndSection

There will still be a graphical glitch when entering the LUKS password but everything else works fine. 

To fix WiFi network you need to use kernel 5.15.64-1.fc32 on sys-net. Most of the time the network adapter works, sometimes it doesn't work on boot but restarting sys-net gets it working. Once I have had to reboot the whole computer to get it working. 

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/01sauU58TsI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CANC2dUd7m1UGFw2dSge2sFMpuU2B_j6obtSEFu1ZGTPWWMnh8Q%40mail.gmail.com.

[Arran Lawley]

Qubes is working for me on Lenovo X1 Carbon gen 10. 

To fix graphical glitches Dom0 needs to use kernel 5.18.16-1.fc32.qubes.x86_64 and create file with "sudo nano /etc/X11/xorg.conf.d/99-intel.conf" and add;

Section "OutputClass"

Identifier "intel"

MatchDriver "i915"

Driver "intel"

Option "AccelMethod" "sna"

Option "TearFree" "true"

Option "DRI" "3"

EndSection

There will still be a graphical glitch when entering the LUKS password but everything else works fine. 

To fix WiFi network you need to use kernel 5.15.64-1.fc32 on sys-net. Most of the time the network adapter works, sometimes it doesn't work on boot but restarting sys-net gets it working. Once I have had to reboot the whole computer to get it working. 

On 28 August 2022 07:42:17 Martin Holst Swende <martin...@gmail.com> wrote:

--

[Arran Lawley]

I just entered "sudo qubes-dom0-update kernel-latest" 

[Martin Holst Swende]

That's odd, since it doesn't seem to work for me.

Related question: I've been searching and haven't found -- where can I check the most recent packages on the various channels (stable / unstable / testing / experimental etc) . Would be nice to be able to check what different kernels are available via what channels.

Cheers ,

[Martin Holst Swende]

Update on this.

I was able to update sys-net to use 5.15.64-1.fc32, and can confirm that it fixed the wifi issues.

I also updated the dom0, to 5.19.9-1.fc32. However, that didn't go as well, and the system now crashes on boot -- sometimes I get to enter the LUKS password, sometimes it crashes before that.

If I do module_blacklist=i915, then I can bypass the crash and enter the system.

/Martin

On 9/20/22 05:36, Arran Lawley wrote:

[Arran Lawley]

Yeah, In the process of trying to get qubes to work I tried 5.19.9-1.fc32 but it kept crashing at the Luks password screen. The only kernel that seems to work is 5.18.16-1.fc32.qubes.x86_64 but if "sudo qubes-dom0-update kernel-latest" doesn't work for you then I don't know how else you would get it. 

[Martin Holst Swende]

I installed an early version: 5.19.14-1  (see https://github.com/QubesOS/qubes-linux-kernel/pull/649#issuecomment-1268337609).

Unfortunately, it didn't solve the issue -- crash at luks screen. However, I did manage to snap a picture of the crash this time. See attached.

/Martin

[Martin Holst Swende]

Follow-up to my last mail, where I posted an image. Here's the
transcribed stack trace, for better indexing by search-engines


```

kernel BUG at mm/slab.h:440!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 9 PID: 717 Comm: udevadm Tainted: G     W
5.19.14-1.fc32.qubes.x86_64 #1
Hardware name: LENOVO 21CBCTO1WW/21CBCTO1WW, BUIS N3AET62W (1.27) 06/24/2022
RIP: e030:memcg_slab_post_alloc_hook+0x21e/0x2c0

... registers...

Call trace:
<TASK>
kmem_cache_alloc+0x1ab/0x2f0
vm_area_dup+0x21/0xa0
? xas_load+0x5/0xa0
? filemap_get_read_batch+0x135/0x2b0
? filemap_get_pages+0xce/0x3e0
? current_time+0x3c/0x100
? current_time+0x3c/0x100
? preempt_count_add+0x4d/0xa0
? preempt_count_add+0x4d/0xa0
? check_preemption_disabled+0x33/0xf0
? touch_atime+0xf5/0x310
? mod_objcg_state+0xe1/0x310
? current_time+0x3c/0x100
__split_vma+0x48/0x1a0
mprotect_fixup+0x269/0x310
do_mprotect_pkey+0x245/0x410
__x64_sys_mprotect+0x1b/0x30
do_syscall_64+0x59/0x90
? do_syscall_64+0x69/0x90
? exc_page_fault+0x76/0x170
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7ccb0032a12

... registers...

</TASK>

```

[Sébastien Chaumat]

Hello,

 Could it be that current sys-gui-gpu cannot work because of  : https://lists.xenproject.org/archives/html/xen-devel/2022-10/msg01820.html ?

[Martin Holst Swende]

Another follow-up:

I now installed kernel version `6.0.7-1.fc32.qubes.x84_64`, and now I
get past the crash at the luks-screen.

I am not 100% sure which kernel fixed it, but ISTR trying with an
earlier 6.0-version a few weeks ago without success.

Going to test a bit more, but looks good so far!

[Martin Holst Swende]

Another follow-up. The audio (tested via a fedora-based work-qube) is
hilariously distorted. Listening to some music through it made it sound
like some extremely experimental avant-garde stuff.