You are not logged in.
## Summary
Since the early-June package update, Firefox alone freezes on a regular
clockwork cycle: roughly 5 seconds frozen, 5 seconds responsive, repeating.
The rest of the desktop is unaffected. The frozen Firefox is **blocked /
sleeping**, not burning CPU — so it is waiting on something, not computing.
## System
| | |
|---|---|
| Distro | Arch Linux (rolling) |
| Compositor | Sway 1.12 |
| Firefox | 151.0.4 |
| GPU | AMD Lucienne APU (integrated, `amdgpu`, Mesa 26.1.2) |
| Kernel | 7.0.11.arch1-1 |
| Session | Wayland |
Relevant packages from the update batch that preceded the problem (`/var/log/pacman.log`):
```
2026-06-04 mesa 26.0.6 -> 26.1.2
2026-06-04 firefox 150.0.2 -> 151.0.3
2026-06-04 linux 7.0.5 -> 7.0.11
2026-06-04 sway 1.11 -> 1.12
2026-06-04 pipewire 1.6.4 -> 1.6.6
2026-06-11 firefox 151.0.3 -> 151.0.4 (problem persists)
```
## What I have ruled out
- **GPU / Mesa / WebRender** — launching with `LIBGL_ALWAYS_SOFTWARE=1`
(software rendering) still freezes.
- **Wayland vs XWayland** — `MOZ_ENABLE_WAYLAND=0` (XWayland) still freezes.
- **Profile / extensions** — a clean throwaway profile
(`firefox --no-remote --profile $(mktemp -d)`) with no extensions still freezes.
- **System-wide compositor stall** — a `while true; do date; sleep 0.25; done`
loop in a terminal ticks perfectly smoothly the whole time; only Firefox
hitches. Sway itself is fine.
- **GPU hangs/resets** — `journalctl -b -k | grep -iE 'amdgpu|reset|ring|fence|timeout'`
shows only normal init, no ring timeouts or GPU resets.
- **CPU-bound** — `top` shows the CPU ~98% idle during the freezes;
`iowait` ~0. The Firefox processes sit in **S** (interruptible sleep) state,
never **D** (disk wait), never pegged. It is blocked on a wait, not working.
So: independent of render backend, independent of profile, system compositor
healthy, CPU idle — the Firefox main thread is blocking on a syscall every ~5s.
## Steps to reproduce
1. Arch with Sway on an AMD APU, Firefox 151, after the early-June update.
2. Start Firefox, open any page.
3. UI freezes ~5s, recovers ~5s, repeats indefinitely.
## Question
What is the ~5s blocking syscall above waiting on, and has anyone else seen
this regression after the early-June `firefox` / `mesa` / `sway` / `kernel`
bump? Happy to test downgrades or `about:config` toggles.
Last edited by werwer (2026-06-12 07:57:15)
Offline
https://bbs.archlinux.org/help.php#bbcode
Is this also the case when *exclusively* opening this webpage?
My gut feeling is pipewire - make sure you've pipewire-pulse and not pulseaudio (ie. colliding daemons) and see https://wiki.archlinux.org/title/WirePl … t_settings
Does this also happen for a completely fresh user account?
Offline
yes fresh profile same issue. It happens on every page including settings ones and even profile selecting one. also happens in safe mode.
Last edited by werwer (2026-06-12 16:42:53)
Offline
Does this also happen on a new user account? Although not the same issue, I recently upgraded one of my old PCs from June 2025 to the latest, and had very similar symptoms with Firefox. However, I recreated the profile and it has been working since then.
Offline
Thanks seth — good catch on the daemons. You were half right: I did have colliding servers — both pulseaudio and pipewire were running at the same time:
1555 /usr/bin/pulseaudio --daemonize=no --log-target=journal
1901 /usr/bin/pipewire
pulseaudio was still installed, and I had no wireplumber or pipewire-pulse. So I cleaned it up properly:
sudo pacman -S pipewire-pulse wireplumber # removed pulseaudio on conflict
systemctl --user enable --now pipewire pipewire-pulse wireplumber
After a re-login the stack is correct now:
1514 /usr/bin/pipewire
1515 /usr/bin/wireplumber
1517 /usr/bin/pipewire-pulse
Definitely a real misconfig I'm glad to have fixed — but unfortunately the freezing is unchanged. Still ~5s frozen / ~5s responsive, Firefox only.
Offline
it does NOT freeze if i log in to a different OS-level user account. Weird. But it still freezes if i create new firefox user/profile.
Offline
So, something else needs a config reset. Do you have any custom pipewire/pulse config? Other places to look for are gtk, dconf, etc.
Offline
More importantly does it still happen after a re-login after replacing PA?
nb. you don't have to start/enable those services, PW is socket activated.
5s frequency sounds like some timeout - sure it's not logged in the system journal at all (nb. that there's no guarantee that there'll be some error saying "timeout", more likely some message every 5s)
Is your network stable?
Offline