I only wanted to update my machine.

You know. Normal Linux user hubris.

A little pacman -Syu, a reboot, maybe five minutes of smug satisfaction because the system came back up. Instead I got the classic Linux desktop experience: login weirdness, missing panels, Bluetooth vanishing into the void, and me yelling at a computer like it personally betrayed my bloodline.

This is the story of how I fixed my Arch install by not trusting the new kernel.

The machine#

My little archbox an ASUS ProArt PX13 / AI MAX system running Arch Linux with Wayland and niri.

The important hardware villain:

MediaTek MT7925 Wi-Fi 7 / Bluetooth combo chip
Wi-Fi PCI device: 14c3:7925
Bluetooth USB device: 13d3:3602 IMC Networks Wireless_Device

The working kernel:

7.0.5-arch1-1

The bastard kernel:

7.0.7-arch1-1

First problem: Niri login was cursed#

After rebooting, SDDM would let me log in, then dump me back, or I would need to log in twice. Then Waybar was gone. Or worse: Waybar existed, but not on the session I was actually looking at.

Very cool. Very normal. Very “desktop Linux is ready for everyone”.

The logs showed Niri starting through the packaged session wrapper:

/usr/bin/niri-session

That wrapper goes through user systemd. On my setup it could start Niri before the SDDM/logind seat was ready, so Niri tried to touch DRM and got smacked:

/dev/dri/card1
Permission denied
session is not active

So the workaround was a local shim:

~/.local/bin/niri-session

with:

#!/bin/sh
exec /usr/bin/niri --session

And SDDM needed to actually find that first, so ~/.zprofile now has:

export PATH="$HOME/.local/bin:$PATH"

This made Niri login again.

Then came the second punch.

Waybar was starting a ghost Niri#

My waybar.service was enabled in default.target and had this wonderful little footgun:

Requires=niri.service

So user systemd started Waybar, Waybar required Niri, systemd spawned a second Niri, and then I had one real SDDM-launched Niri plus one cursed headless/early Niri. Waybar attached to the wrong one.

Absolute clown circus.

The fix:

  • remove Requires=niri.service
  • stop enabling Waybar from default.target
  • start/restart Waybar from the actual Niri startup after the real session environment exists

The Niri config now imports the real Wayland environment and restarts Waybar from inside the real session:

systemctl --user import-environment WAYLAND_DISPLAY DISPLAY XDG_CURRENT_DESKTOP XDG_SESSION_TYPE NIRI_SOCKET
systemctl --user restart waybar.service

Now I get one Niri and one Waybar. Revolutionary technology.

Second problem: Bluetooth went to hell#

After the kernel update, Bluetooth just stopped being Bluetooth.

On 7.0.7-arch1-1:

bluetoothctl show

said:

No default controller available

The kernel log said:

Bluetooth: hci0: Failed to send wmt func ctrl (-22)
Bluetooth: hci0: HCI Enhanced Setup Synchronous Connection command is advertised, but not supported.

The device was physically there:

13d3:3602 IMC Networks Wireless_Device

The driver was there:

btusb
btmtk
bluetooth

The service was running. The chip showed up. But BlueZ had no usable controller.

So, yes, the machine could see the Bluetooth chip. It just could not use the damn thing.

The forum rabbit hole#

This is not just me. MT7925 Bluetooth is apparently a small festival of pain.

Useful links I found:

Common symptoms in the threads:

Execution of wmt command timed out
Failed to send wmt func ctrl
Failed to send wmt patch dwnld
No default controller available
Bluetooth disappears until full power cycle

People mention power cycling, firmware weirdness, autosuspend, kernel regressions, and the chip holding onto broken state like it has emotional trauma.

Autosuspend mitigation#

The first mitigation was to stop USB autosuspend from poking the Bluetooth side of the MT7925.

Module option:

/etc/modprobe.d/btusb-no-autosuspend.conf

options btusb enable_autosuspend=0

Targeted udev rule:

/etc/udev/rules.d/99-mt7925-bt-no-autosuspend.rules

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="13d3", ATTR{idProduct}=="3602", TEST=="power/control", ATTR{power/control}="on"

Then:

sudo udevadm control --reload-rules
sudo udevadm trigger -s usb
sudo mkinitcpio -P

The settings applied:

But on 7.0.7, Bluetooth was still dead. So no, autosuspend was not enough.

The actual fix: roll back the kernel#

The moment of clarity was simple:

  • 7.0.7: Bluetooth dead
  • roll back to 7.0.5

Then Bluetooth was visible again:

bluetoothctl show

Controller EC:3A:56:11:91:B3 (public)
Powered: yes
PowerState: on

Moral of the story#

Arch did exactly what Arch does: gave me the new shiny thing immediately.

And now the machine works again.

For today.