Problem Description:
After upgrading to 26.04 LTS on a Thinkpad x13s, opening the Mouse & Touchpad menu in settings causes an instant system crash. That’s it. Nothing else needed to reproduce.
Rather annoyingly, there isn’t really much in the logs. journalctl -k -b -1 doesn’t give much:
Jun 05 09:02:19 bullfinch kernel: rfkill: input handler disabled
Jun 05 09:04:48 bullfinch kernel: kauditd_printk_skb: 11 callbacks suppressed
Jun 05 09:05:06 bullfinch kernel: ath11k_pci 0006:01:00.0: msdu_done bit in attention is not set
I used Claude, ChatGPT and Gemini together to collaborate on this answer. It feels sane to me, but you may want to double check before doing this.
This smells like a kernel panic or a hardware bus lockup, which happens when the system drops dead before it can flush logs to the disk.
The fact that gsettings works perfectly confirms that the software configuration stack is fine. The crash only happens when the GNOME control center UI opens and actively probes the physical hardware (for things like multi-touch capabilities or power states). On the ThinkPad X13s (Snapdragon ARM64), this relies on specific Qualcomm power domains and I2C drivers. An unexpected hardware query here is likely hanging the system bus.
Here is how to isolate and capture the exact cause:
1. Isolate GNOME vs. The Kernel Stack (libinput)
Since gsettings is fine, we need to see if simply querying the hardware outside of the GNOME interface triggers the identical crash.
Install the input utilities and run these from a standard terminal:
sudo apt install libinput-tools
Test 1 (Just list the hardware devices):sudo libinput list-devices
Test 2 (Monitor input events):sudo libinput debug-events(move your finger on the trackpad while running this)
The Outcome:
If it crashes here: It is likely a Kernel/Driver bug (possibly in i2c-hid, i2c-qcom-geni, or the Qualcomm pin controller).
If these work fine but GNOME still crashes: It is a User-space bug (likely a GNOME/Wayland interaction trying to read an unmapped hardware property).
2. Capture the “Dying Breath” via SSH
Because local logs aren’t writing to disk fast enough before the hardware resets, the most reliable way to catch the error message is over the network.
Connect to your X13s via SSH from another computer or phone.
In the SSH terminal, run a live kernel monitor: sudo dmesg -Tw
On the X13s laptop, open the Mouse & Touchpad settings to trigger the crash.
Watch the SSH terminal. The kernel will often spit out a Kernel Panic or I2C bus timeout over the network terminal a millisecond before the laptop dies.
3. Test with an External Mouse
Plug in a standard USB wired mouse or wireless dongle.
If the panel opens perfectly with an external mouse but crashes only when attempting to read the built-in Elan/Synaptics I2C trackpad devices shown in your lshw, it confirms a power management or clock-gating bug in the Qualcomm I2C stack when GNOME tries to toggle features like natural scrolling.
Next Steps for Bug Reporting
If Step 1 crashes the machine, file the bug against the kernel rather than GNOME using: ubuntu-bug linux
Explicitly mention that this is on the ThinkPad X13s (ARM64), as the Qualcomm laptop stack undergoes heavy changes between Ubuntu release cycles.
Make that journalctl -f, because the journal is actually the consumer of kmsg and only forwards to the dmesg buffer, if I understand the systemd-journald interaction correctly. Plus, everything will be visible, not just the kernel messages/panic, but hopefully also what happened right before.
It may even be worthwhile to set up systemd-journald-remote and not use any form of network encryption, like the SSH tunnel which could contribute to the system not being able to flush out those messages in time before the system goes down.
If there is some way to get to a serial port, possibly with a USB device, that’d be an even better way of doing it – no network stack – ; console=ttyUSB0 is the kernel parameter for this, except the index might be different, so could be ttyUSB1 or whatever.
The point is that those message never make it to persistent storage but might still be visible in the SSH session which follows the (in memory) log in realtime. Also, at least use telnet, if it must be over the network, so as to not add encryption overhead — but do disable or purge telnet after it served this very narrow purpose; it’s dangerous in most any other context.
Okay, so, I haven’t gotten any more logs, but I do have a bit of a smoking gun: hardware acceleration. If I leave hardware acceleration enabled in Firefox, it’ll eventually crash in an identical fashion. No logs, no nothing, just hard-crash. Turn off hardware acceleration, no crashes. I wonder if something similar could be happening here?
Alright, so, it’s possible I’m barking up the wrong tree, but I noticed that running gnome-control-center will instantly reproduce the crash. I tried MESA_LOADER_DRIVER_OVERRIDE=swrast gnome-control-center and that just dumped core. Trace looks like this:
#0 drisw_init_screen (screen=0xbee0295f3f60, driver_name_is_inferred=false) at ../src/gallium/frontends/dri/drisw.c:611
#1 0x0000f8176c52253c in driCreateNewScreen3 (scrn=scrn@entry=0, fd=-1, loader_extensions=0xf817d4780c60 <dri2_loader_extensions>, type=type@entry=DRI_SCREEN_SWRAST, driver_configs=0xbee0293d63e0,
driver_name_is_inferred=driver_name_is_inferred@entry=false, has_multibuffer=<optimized out>, data=data@entry=0xbee028bb3650) at ../src/gallium/frontends/dri/dri_util.c:136
#2 0x0000f817d4744200 in dri2_create_screen (disp=disp@entry=0xbee028bb3650) at ../src/egl/drivers/dri2/egl_dri2.c:795
#3 0x0000f817d474ddec in dri2_initialize_wayland_drm (disp=0xbee028bb3650) at ../src/egl/drivers/dri2/platform_wayland.c:2735
#4 dri2_initialize_wayland (disp=disp@entry=0xbee028bb3650) at ../src/egl/drivers/dri2/platform_wayland.c:3288
#5 0x0000f817d4744a50 in dri2_initialize (disp=disp@entry=0xbee028bb3650) at ../src/egl/drivers/dri2/egl_dri2.c:895
#6 0x0000f817d4734070 in eglInitialize (dpy=<optimized out>, major=0xffffd4c25604, minor=0xffffd4c25600) at ../src/egl/main/eglapi.c:697
#7 0x0000f8183e073a80 in ?? () from /usr/lib/aarch64-linux-gnu/libgtk-4.so.1
#8 0x0000f8183e00ffc8 in ?? () from /usr/lib/aarch64-linux-gnu/libgtk-4.so.1
#9 0x0000f8183e073404 in gdk_display_prepare_gl () from /usr/lib/aarch64-linux-gnu/libgtk-4.so.1
#10 0x0000f8183e073760 in gdk_display_create_gl_context () from /usr/lib/aarch64-linux-gnu/libgtk-4.so.1
Given that this is a Snapdragon device — BTW, why did I have to find out by searching for it? Support-Template hint dropped —, I highly suspect it’s driver / device tree related. The last message in this thread seems to be the solution; I’ve only just read some of the initial message once, so can’t say much else.
—, I highly suspect it’s driver / device tree related. The last message in this thread seems to be the solution; I’ve only just read some of the initial message once, so can’t say much else.