On a successful login the GUI session freezes after a few seconds when using hwe kernel

[Joao Andre Simioni]

[Description]

Running a Jammy Desktop inside Hyper-V, with the hwe kernel (tested with 5.19 and 6.2), around 10 seconds after a successful login, the UI freezes.

If switching tty to tty1 using CTRL + ALT + F1 and returning to tty2 using CTRL + ALT + F2 the UI responds again, for a short time (around 10 seconds).

[Workaround]

Switching back to the LTS Kernel (5.15) brings the system back to normal operation.
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu82.4
Architecture: amd64
CasperMD5CheckResult: pass
DisplayManager: gdm3
DistroRelease: Ubuntu 22.04
GsettingsChanges:

InstallationDate: Installed on 2023-06-20 (6 days ago)
InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223)
Package: gnome-shell 42.5-0ubuntu1
PackageArchitecture: amd64
ProcVersionSignature: Ubuntu 5.19.0-42.43~22.04.1-generic 5.19.17
RelatedPackageVersions: mutter-common 42.5-0ubuntu1
Tags: jammy
Uname: Linux 5.19.0-42-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: N/A
_MarkForUpload: True
---
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu82.4
Architecture: amd64
CasperMD5CheckResult: pass
DistUpgraded: Fresh install
DistroCodename: jammy
DistroRelease: Ubuntu 22.04
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:

InstallationDate: Installed on 2023-06-20 (6 days ago)
InstallationMedia: Ubuntu 22.04.2 LTS "Jammy Jellyfish" - Release amd64 (20230223)
Lspci:

Lspci-vt: -[0000:00]-
Lsusb: Error: command ['lsusb'] failed with exit code 1:
Lsusb-t:

Lsusb-v: Error: command ['lsusb', '-v'] failed with exit code 1:
MachineType: Microsoft Corporation Virtual Machine
Package: xorg 1:7.7+23ubuntu2
PackageArchitecture: amd64
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.19.0-42-generic root=UUID=194597a3-7adc-445c-978b-d1db2026d95a ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 5.19.0-42.43~22.04.1-generic 5.19.17
Tags: jammy ubuntu
Uname: Linux 5.19.0-42-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: N/A
_MarkForUpload: True
dmi.bios.date: 11/26/2012
dmi.bios.release: 1.0
dmi.bios.vendor: Microsoft Corporation
dmi.bios.version: Hyper-V UEFI Release v1.0
dmi.board.asset.tag: None
dmi.board.name: Virtual Machine
dmi.board.vendor: Microsoft Corporation
dmi.board.version: Hyper-V UEFI Release v1.0
dmi.chassis.asset.tag: 7287-2454-0075-8144-0704-7909-41
dmi.chassis.type: 3
dmi.chassis.vendor: Microsoft Corporation
dmi.chassis.version: Hyper-V UEFI Release v1.0
dmi.modalias: dmi:bvnMicrosoftCorporation:bvrHyper-VUEFIReleasev1.0:bd11/26/2012:br1.0:svnMicrosoftCorporation:pnVirtualMachine:pvrHyper-VUEFIReleasev1.0:rvnMicrosoftCorporation:rnVirtualMachine:rvrHyper-VUEFIReleasev1.0:cvnMicrosoftCorporation:ct3:cvrHyper-VUEFIReleasev1.0:skuNone:
dmi.product.family: Virtual Machine
dmi.product.name: Virtual Machine
dmi.product.sku: None
dmi.product.version: Hyper-V UEFI Release v1.0
dmi.sys.vendor: Microsoft Corporation
version.compiz: compiz N/A
version.libdrm2: libdrm2 2.4.113-2~ubuntu0.22.04.1
version.libgl1-mesa-dri: libgl1-mesa-dri 22.2.5-0ubuntu0.1~22.04.1
version.libgl1-mesa-glx: libgl1-mesa-glx N/A
version.xserver-xorg-core: xserver-xorg-core 2:21.1.3-2ubuntu2.9
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:19.1.0-2ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20210115-1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.17-2build1

[Joao Andre Simioni (jasimioni)]

journalctl logs

[Daniel van Vugt (vanvugt)]

Thanks for the bug report. I don't see any crashes or graphics-related errors so this may need a developer to set up a similar Hyper-V installation to investigate further.

In the meantime, can you identify the upstream kernel version that the problem started in?
https://kernel.ubuntu.com/~kernel-ppa/mainline/?C=M;O=D

[Daniel van Vugt (vanvugt)]

Just in case, please also check to see if there are any files in /var/crash/ and if so then:
https://wiki.ubuntu.com/Bugs/Responses#Missing_a_crash_report_or_having_a_.crash_attachment

[Joao Andre Simioni (jasimioni)]

Hi Daniel,

There are no crashes, and we don't see the UI crashing, only freezing. If switching to tty1 and back to tty2, the session continues at the same point it was before, for around ten seconds, and then it's frozen again.

This is the logs that show up when doing that switching: https://pastebin.ubuntu.com/p/wdHV3mcbhW/

I'll check which kernel introduces the error and post the outcome.

[Joao Andre Simioni (jasimioni)]

I was not able to reproduce the error with the 5.19 mainline kernels. But I tracked the available Jammy kernels, and the problem starts in:

linux-image-5.19.0-42-generic

I don't see the issue with the -41-generic

Does this help? Let me know if I can provide additional info here.

[Daniel van Vugt (vanvugt)]

Likely the bug got introduced in linux-image-5.19.0-42-generic from a mainline kernel newer than 5.19 and no older than 6.2.0.

[Daniel van Vugt (vanvugt)]

I can't find any obvious changes between 5.19.0-41-generic and 5.19.0-42-generic that would cause this. Plenty of non-obvious changes are possible...

Can you please attach a log from a working system (5.19.0-41-generic):

  journalctl -b0 > journal-41.txt

and then a non-working system (5.19.0-42-generic) again?

  journalctl -b0 > journal-42.txt

[Joao Andre Simioni (jasimioni)]

This sos report was generated right after collecting the journal-42.txt log files.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

I couldn't find any difference between journal-4[12].txt that I was hoping for...

Next step is probably to reproduce the freeze, then log in via ssh and force the graphics processes (Xorg, gnome-shell) to crash by sending them a signal such as 'kill -ABRT pid'. That will produce a /var/crash/ file which you can then upload with 'ubuntu-bug' or 'apport-cli' and we can analyse what is freezing.

[Joao Andre Simioni (jasimioni)]

apport information

[Joao Andre Simioni (jasimioni)]

apport information

[Joao Andre Simioni (jasimioni)]

apport information

[Joao Andre Simioni (jasimioni)]

apport information

[Joao Andre Simioni (jasimioni)]

apport information

[Joao Andre Simioni (jasimioni)]

apport information

[Joao Andre Simioni (jasimioni)]

apport information

[Joao Andre Simioni (jasimioni)]

apport information

[Joao Andre Simioni (jasimioni)]

apport information

[Joao Andre Simioni (jasimioni)]

Daniel, I have the impression that apport-cli did something wrong here, so I'm attaching the .crash files. At first it complained that linux-hwe-5.19 was not installed, so I ran it with the -p gnome-shell option. Not sure if it picked the already generated file or tried to kill it again.

[Daniel van Vugt (vanvugt)]

Attaching crash files to bugs doesn't usually work, but this time we got lucky. This shows gnome-shell using software rendering to redraw the screen as expected, but being blocked in a wait (as are all threads). So this might be a threading/timing regression in the kernel, or it might be irrelevant because we expect VMs to spend all their time doing software rendering like this anyway. Just not deadlocked like this appears to be.

My only remaining suggestion is to bisect the individual kernel changes :(

https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/jammy/log/?h=Ubuntu-hwe-5.19-5.19.0-42.43_22.04.1

---

The gnome-shell stack trace stuck in Mesa doing software rendering:

#3 0x00007f11f4242476 in __GI_raise (sig=6) at ../sysdeps/posix/raise.c:26
#4 0x0000561bf427f7aa in ()
#5 0x00007f11f4242520 in <signal handler called> () at /lib/x86_64-linux-gnu/libc.so.6
#6 __futex_abstimed_wait_common64
    (private=0, cancel=true, abstime=0x0, op=393, expected=0, futex_word=0x561bf5fbc578)
    at ./nptl/futex-internal.c:57
#7 __futex_abstimed_wait_common
    (cancel=true, private=0, abstime=0x0, clockid=0, expected=0, futex_word=0x561bf5fbc578)
    at ./nptl/futex-internal.c:87
#8 __GI___futex_abstimed_wait_cancelable64
    (futex_word=futex_word@entry=0x561bf5fbc578, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at ./nptl/futex-internal.c:139
#9 0x00007f11f4293ac1 in __pthread_cond_wait_common
    (abstime=0x0, clockid=0, mutex=0x561bf5fbc528, cond=0x561bf5fbc550) at ./nptl/pthread_cond_wait.c:503
#10 ___pthread_cond_wait (cond=0x561bf5fbc550, mutex=0x561bf5fbc528) at ./nptl/pthread_cond_wait.c:627
#11 0x00007f11dd70aced in cnd_wait (cond=<optimised out>, mtx=<optimised out>) at ../src/c11/impl/threads_posix.c:135
#12 0x00007f11ddcbc2c3 in lp_fence_wait (f=f@entry=0x561bf5fbc520) at ../src/gallium/drivers/llvmpipe/lp_fence.c:124
#13 0x00007f11ddcb9594 in llvmpipe_fence_finish
    (screen=<optimised out>, ctx=<optimised out>, fence_handle=0x561bf5fbc520, timeout=18446744073709551615)
    at ../src/gallium/drivers/llvmpipe/lp_screen.c:908
#14 0x00007f11ddcbc531 in llvmpipe_finish
    (pipe=pipe@entry=0x561bf5dc3130, reason=reason@entry=0x7f11de927657 "sotropy")
    at ../src/gallium/drivers/llvmpipe/lp_flush.c:93
#15 0x00007f11ddcbc60f in llvmpipe_flush_resource
    (pipe=pipe@entry=0x561bf5dc3130, resource=0x561bfbff5860, level=level@entry=0, read_only=read_only@entry=1 '\001', cpu_access=cpu_access@entry=0 '\000', do_not_block=do_not_block@entry=0 '\000', reason=0x7f11de927657 "sotropy")
    at ../src/gallium/drivers/llvmpipe/lp_flush.c:132
#16 0x00007f11ddce9e13 in llvmpipe_set_sampler_views
    (pipe=0x561bf5dc3130, shader=PIPE_SHADER_FRAGMENT, start=0, num=1, unbind_num_trailing_slots=0, take_ownership=true, views=0x7ffe044f7440) at ../src/gallium/drivers/llvmpipe/lp_state_sampler.c:153
#17 0x00007f11dd76b04b in update_textures
    (st=0x561bf5fcb770, shader_stage=PIPE_SHADER_FRAGMENT, prog=<optimised out>)
    at ../src/mesa/state_tracker/st_atom_texture.c:271
#18 0x00007f11dd762bd8 in st_validate_state (st=st@entry=0x561bf5fcb770, pipeline=pipeline@entry=ST_PIP...