Mixxx causes kernel panic on linux-zen

Working state:

$ inxi -Faz
System:    Kernel: 5.10.83-1-lts x86_64 bits: 64 compiler: gcc v: 11.1.0
           parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-lts root=UUID=179b848a-d752-453c-8e55-0fb01cf9d4e7 rw
           [email protected] quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
           systemd.unified_cgroup_hierarchy=1 loglevel=3
           Desktop: KDE Plasma 5.23.4 tk: Qt 5.15.2 info: latte-dock wm: kwin_x11 vt: 1 dm: SDDM Distro: Garuda Linux
           base: Arch Linux
Machine:   Type: Laptop System: Hewlett-Packard product: HP Compaq 6720s v: F.0A serial: <superuser required> Chassis:
           type: 10 serial: <superuser required>
           Mobo: Hewlett-Packard model: 30D8 v: KBC Version 83.0E serial: <superuser required> BIOS: Hewlett-Packard
           v: 68MDU Ver. F.0A date: 04/14/2008
Battery:   ID-1: C23B charge: 41.1 Wh (95.6%) condition: 43.0/43.0 Wh (100.0%) volts: 12.4 min: 10.8
           model: Hewlett-Packard Primary type: Li-ion serial: <filter> status: Unknown
CPU:       Info: Dual Core model: Intel Core2 Duo T5670 bits: 64 type: MCP arch: Core Merom family: 6 model-id: F (15)
           stepping: D (13) microcode: A4 cache: L1: 128 KiB L2: 4 MiB
           flags: ht lm nx pae sse sse2 sse3 ssse3 bogomips: 7181
           Speed: 1795 MHz min/max: 800/1801 MHz boost: enabled Core speeds (MHz): 1: 1795 2: 1825
           Vulnerabilities: Type: itlb_multihit status: KVM: VMX unsupported
           Type: l1tf mitigation: PTE Inversion
           Type: mds status: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
           Type: meltdown mitigation: PTI
           Type: spec_store_bypass status: Vulnerable
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization
           Type: spectre_v2 mitigation: Full generic retpoline, STIBP: disabled, RSB filling
           Type: srbds status: Not affected
           Type: tsx_async_abort status: Not affected
Graphics:  Device-1: Intel Mobile GME965/GLE960 Integrated Graphics vendor: Hewlett-Packard driver: i915 v: kernel
           bus-ID: 00:02.0 chip-ID: 8086:2a12 class-ID: 0300
           Display: x11 server: X.Org compositor: kwin_x11 driver: loaded: intel unloaded: modesetting
           alternate: fbdev,vesa display-ID: :0 screens: 1
           Screen-1: 0 s-res: 1280x800 s-dpi: 96 s-size: 338x211mm (13.3x8.3") s-diag: 398mm (15.7")
           Monitor-1: LVDS1 res: 1280x800 hz: 60 dpi: 99 size: 330x210mm (13.0x8.3") diag: 391mm (15.4")
           Message: Unable to show advanced data. Required tool glxinfo missing.
Audio:     Device-1: Intel 82801H HD Audio vendor: Hewlett-Packard driver: snd_hda_intel v: kernel bus-ID: 00:1b.0
           chip-ID: 8086:284b class-ID: 0403
           Sound Server-1: ALSA v: k5.10.83-1-lts running: yes
           Sound Server-2: JACK v: 1.9.19 running: no
           Sound Server-3: PulseAudio v: 15.0 running: no
           Sound Server-4: PipeWire v: 0.3.40 running: yes
Network:   Device-1: Intel 82562GT 10/100 Network vendor: Hewlett-Packard driver: e1000e v: kernel port: 4020
           bus-ID: 00:19.0 chip-ID: 8086:10c4 class-ID: 0200
           IF: enp0s25 state: down mac: <filter>
           Device-2: Realtek RTL8188EUS 802.11n Wireless Network Adapter type: USB driver: r8188eu bus-ID: 2-2:2
           chip-ID: 0bda:8179 class-ID: 0000 serial: <filter>
           IF: wlp0s29f7u2 state: up mac: <filter>
Bluetooth: Device-1: Cambridge Silicon Radio Bluetooth Dongle (HCI mode) type: USB driver: btusb v: 0.8 bus-ID: 7-1:2
           chip-ID: 0a12:0001 class-ID: e001
           Report: bt-adapter ID: hci0 rfk-id: 1 state: up address: <filter>
Drives:    Local Storage: total: 111.79 GiB used: 108.72 GiB (97.3%)
           SMART Message: Unable to run smartctl. Root privileges required.
           ID-1: /dev/sda maj-min: 8:0 vendor: PNY model: SSD2SC120G1CS1754D117-551 size: 111.79 GiB block-size:
           physical: 512 B logical: 512 B speed: 3.0 Gb/s type: SSD serial: <filter> rev: 1101 scheme: MBR
Partition: ID-1: / raw-size: 111.79 GiB size: 111.79 GiB (100.00%) used: 108.72 GiB (97.3%) fs: btrfs dev: /dev/sda1
           maj-min: 8:1
           ID-2: /home raw-size: 111.79 GiB size: 111.79 GiB (100.00%) used: 108.72 GiB (97.3%) fs: btrfs dev: /dev/sda1
           maj-min: 8:1
           ID-3: /var/log raw-size: 111.79 GiB size: 111.79 GiB (100.00%) used: 108.72 GiB (97.3%) fs: btrfs
           dev: /dev/sda1 maj-min: 8:1
           ID-4: /var/tmp raw-size: 111.79 GiB size: 111.79 GiB (100.00%) used: 108.72 GiB (97.3%) fs: btrfs
           dev: /dev/sda1 maj-min: 8:1
Swap:      Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
           ID-1: swap-1 type: zram size: 3.83 GiB used: 560 MiB (14.3%) priority: 100 dev: /dev/zram0
Sensors:   System Temperatures: cpu: 59.0 C mobo: 26.6 C
           Fan Speeds (RPM): N/A
Info:      Processes: 203 Uptime: 4m wakeups: 1 Memory: 3.83 GiB used: 1.88 GiB (49.1%) Init: systemd v: 249
           tool: systemctl Compilers: gcc: 11.1.0 clang: 13.0.0 Packages: pacman: 1368 lib: 345 Shell: fish v: 3.3.1
           default: Bash v: 5.1.12 running-in: yakuake inxi: 3.3.09

Non-working looks the same but with

System:    Kernel: 5.15.5-zen1-1-zen x86_64 bits: 64 compiler: gcc v: 11.1.0

I'm not sure exactly when this started, I think it might've been with the move to 5.15 from 5.14. I run Mixxx, the whole kernel crashes. No caps-lock-light, gotta hard reboot, etc.

Installing and rebooting into linux-lts mitigates the problem.

about to trigger it again to confirm above kernel version crashes, will edit this after rebooting from the crash.


How about 5.15 mainline?

Just checked, that also crashes

Could this be a Garuda specific issue? Perhaps pipewire-specific? Is this replicable?



An old weak laptop , with too little RAM, integrated GPU and the most performance-hungry DE. At some point it crashes.


@scott sounds like you should look into using one of Garuda WM editions. It’s makes my old laptop run like a champ.

1 Like

that's not what's going on here. It's not using anywhere near too much RAM, and i've produced several multi-hour radio programs with this hardware setup on a more stable kernel. I'm gonna go do it again in a couple hours on the 5.10 one, and it'll go fine.

also it's not the desktop that's crashing. It's the kernel. Just because I'm using old hardware doesn't mean I'm a noob

1 Like

My system specs are also not that great.

So, I installed mixxx and it is running butter smooth, with firedragon, telegram-desktop and xed running side by side.

(I am using Cinnamon Edition, btw)

So, how did you install mixxx? I installed mixxx package and not mixxx-git
And obviously, neither kernel nor pulse audio are responsible for your issue.

I only have few songs from old CD, but they sound good

PS: It is a really nice software. Considering DJ as career option now


Reads as if the system collapses after starting the app.




Who claimed that?

Translated with www.DeepL.com/Translator (free version)

The standard mixxx package in the repo

yes, but not due to lack of resources. Running mixxx on linux 5.10 with nothing else open consumes less than half the available RAM. I regularly open firefox during the (radio) program (to check lyrics for swears) with no fear of OOM kicking in.

So you're suggesting I bring this to LKML? Is there any information which might be specific to Garuda which might be helpful in reporting this to them?

Apologies if I read wrong, it seemed like you were dismissing the issue as the desktop crashing due to lack of resources, assuming I didn't have the experience to recognize a proper kernel crash.

(on an off-topic note, I disagree pretty strongly that Plasma is inherently a performance-hungry DE. I've turned off all the animations and crap and it runs really smooth, even a "weak old laptop" :wink:)

Yeah i used that too. And its working fine here. I must say that its not a very hefty software.

I am really out of clues what might be causing the issue. May be you should try clean install if nothing else works.


thanks. I guess it'll probably come to that. Maybe if I clear out the mixxx configs or something.

Regardless, thanks for letting me know it's a problem on my end not a bug in mixxx or the kernel

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.