Ben Leskey's Blog: debugging

Fixing Intellj IDEA lag spikes on OpenSUSE KDE Plasma 6

Thu, 17 Apr 2025 12:00:00 +0000

I ran into JBR-6830. When using Intellij IDEA on KDE Plasma 6 (OpenSUSE Tumbleweed), I was getting random very noticeable lag spikes. The solution was to add

-Dwatch.desktop.geometry=false

to the Intellij IDEA custom VM options. No more lag spikes!

Fixing HP Victus 15 internal microphone drivers by compiling patched auto-updating kernel with openSUSE Tumbleweed Open Build Service

Wed, 25 Dec 2024 12:00:00 +0000

I've recently moved to a new laptop. OpenSUSE tumbleweed is still my OS of choice, and my recent experience cemented its position as my favorite Linux distro. My new device is an HP Victus 15, specs below:

Operating System: openSUSE Tumbleweed 20241222
KDE Plasma Version: 6.2.4
KDE Frameworks Version: 6.9.0
Qt Version: 6.8.1
Kernel Version: 6.12.6-5.gfb072de-default (64-bit)
Graphics Platform: X11
Processors: 12 × AMD Ryzen 5 7535HS with Radeon Graphics
Memory: 14.8 GiB of RAM
Graphics Processor: AMD Radeon 660M
Manufacturer: HP
Product Name: Victus by HP Gaming Laptop 15-fb2xxx

The only hardware issue encountered on this device was that the internal microphone was not recognized. For example, using arecord -l to list my sound devices, I only saw the unplugged microphone device, even though my devices were shown in inxi -A:

$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 2: Generic_1 [HD-Audio Generic], device 0: ALC245 Analog [ALC245 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

$ inxi -A
Audio:
  Device-1: Advanced Micro Devices [AMD/ATI] Navi 21/23 HDMI/DP Audio
    driver: snd_hda_intel
  Device-2: Advanced Micro Devices [AMD/ATI] Rembrandt Radeon High
    Definition Audio driver: snd_hda_intel
  Device-3: Advanced Micro Devices [AMD] ACP/ACP3X/ACP6x Audio Coprocessor
    driver: snd_pci_acp6x
  Device-4: Advanced Micro Devices [AMD] Family 17h/19h/1ah HD Audio
    driver: snd_hda_intel
  API: ALSA v: k6.12.6-5.gfb072de-default status: kernel-api
  Server-1: PipeWire v: 1.2.7 status: active

After much research I found the fix. I needed to add a linux kernel quirk patch for my specific model in the ACP6X sound driver for the internal microphone. The patch to the kernel itself is extremely simple, just adding my hardware to the quirk list so that even though Linux does not autodetect the correct driver, it will load it anyway:


diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index ecf57a6..c95198c 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -458,6 +458,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
 			DMI_MATCH(DMI_PRODUCT_NAME, "OMEN by HP Gaming Laptop 16z-n000"),
 		}
 	},
+	{
+		.driver_data = &acp6x_card,
+		.matches = {
+			DMI_MATCH(DMI_BOARD_VENDOR, "HP"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Victus by HP Gaming Laptop 15-fb2xxx"),
+		}
+	},
 	{
 		.driver_data = &acp6x_card,
 		.matches = {

So far, so good. But here's where OpenSUSE shines: using the Open Build Service, I was able to create a new set of kernel packages with my patch that automatically keep up with the latest tumbleweed kernel. This reddit comment was very helpful, reproduced below:

Go to https://build.opensuse.org/package/show/openSUSE:Factory/kernel-source

sign in

click branch

optional step - use the command line tool osc to download, edit and test the build locally.

overwrite the config.tar.bz2 with your .config tar bzipped

Make package links to kernel-source and call them kernel-default, kernel-devel and kernel-syms

~~Draw the rest of the owl~~

Wait for it to build successfully

Add the repo to your TW installation (links are on the webpage) and switch the kernel packages over

I more or less followed these steps, with some details below:

First, I installed the kernel-source package so I could test and install my fix locally, using the following:


$ cd linux-build-directory

$ make -C /usr/src/linux O=$PWD oldconfig # Create a kernel config based on my running kernel config
[...]

# In the .config file, I updated CONFIG_LOCALVERSION to differentiate my compiled kernel,
# and removed the reference to the OpenSUSE keys in CONFIG_MODULE_SIG_KEYS

# I also added a modprobe configuration file:
$ cat /etc/modprobe.d/10-unsupported-modules.conf
allow_unsupported_modules 1

$ make -j12 # It builds.

$ sudo make modules_install -j12 # Adds the kernel modules to /usr/lib/modules

$ sudo make install -j12 # Installs the kernel to /boot and updates the bootloader

At this point I created the patch diff of my changes using the original file and my new file:


$ git diff /tmp/old-acp6x-mach.c ./sound/soc/amd/yc/acp6x-mach.c > /tmp/my-new-patch.patch

After this, I rebooted into my custom kernel to verify the fix. To remove the custom compiled kernel from the bootloader list, I just removed the files and updated the bootloader:


$ cd /boot
$ mkdir /home/user/old-linux
$ find | grep my-custom-kernel | sudo xargs -O{} -n1 mv {} /home/user/old-linux # Replace my-custom-kernel with what you put in CONFIG_LOCALVERSION
$ sudo update-bootloader # Get the removed custom kernel off the bootloader menu

I then:

"Branched" a new package from the openSUSE tumbleweed kernel-source package. This created my own kernel-source package that I could modify as needed. Importantly, it is linked to the upstream openSUSE kernel, so it will stay up to date while applying my patches.
Checked out my new package locally, using osc: $ osc -A https://api.opensuse.org checkout home:linewriter1024:branches:Kernel:stable/kernel-source

Linked repos as mentioned in the reddit comment + some additional.


$ osc linkpac home:linewriter1024:branches:Kernel:stable/kernel-source home:linewriter1024:branches:Kernel:stable/kernel-default
$ osc linkpac home:linewriter1024:branches:Kernel:stable/kernel-source home:linewriter1024:branches:Kernel:stable/kernel-devel
$ osc linkpac home:linewriter1024:branches:Kernel:stable/kernel-source home:linewriter1024:branches:Kernel:stable/kernel-docs
$ osc linkpac home:linewriter1024:branches:Kernel:stable/kernel-source home:linewriter1024:branches:Kernel:stable/kernel-syms
$ osc linkpac home:linewriter1024:branches:Kernel:stable/kernel-source home:linewriter1024:branches:Kernel:stable/kernel-macros

Added my patch to patches.addon.tar.bz2 inside my checked out directory, which has an empty directory patches.addon, into which directory I added my patch file 6.12.6-9999-local.patch and a text file named series with one line: 6.12.6-9999-local.patch, the name of the patch file.

Ran osc build and verified that my patch was being used:


$ cat /var/tmp/build-root/standard-x86_64/.build.log | grep addon
[   10s] + /usr/lib/rpm/rpmuncompress -x /home/abuild/rpmbuild/SOURCES/config.addon.tar.bz2
[   10s] + /usr/lib/rpm/rpmuncompress -x /home/abuild/rpmbuild/SOURCES/patches.addon.tar.bz2
[   22s] + patch -s -F0 -E -p1 --no-backup-if-mismatch -i /home/abuild/rpmbuild/BUILD/kernel-source-6.12.6/patches.addon/6.12.6-9999-local.patch

Ran osc commit and uploaded my changes. The open build service built my new kernel and after it was finished I added the repository to my package repositories and ran sudo zypper dup --from=https://download.opensuse.org/repositories/home:/linewriter1024:/branches:/Kernel:/stable/standard/ --allow-vendor-change to upgrade my kernel to my new patched version.
Rebooted and profited!

This OpenSUSE infrastructure is incredibly useful, and I am very pleased with my choice of distro and the (relative!) ease of fixing this internal microphone issue without sacrificing update flow. Next step, getting this patch into the upstream Linux kernel!

Debugging slow boot and a clogged router

Wed, 08 Mar 2023 12:00:00 +0000

I powered on my laptop yesterday morning and saw the Ubuntu boot had stalled on two systemd services: trying to mount a disk by UUID, with a 90 second timeout, and waiting for the network to come up, with no timeout. Before the 90 seconds for mounting the disk was up, the boot continued and I got to the graphical login menu. Network manager tried to connect to my friends' home Wi-Fi, but the connection failed.

This was odd:

I had never seen these messages before during boot.
I had not installed or upgraded new software for several days.
I had not recently changed system configuration.
My phone was connected to the same Wi-Fi that my laptop could not connect to.

Hypothesis 1: Something was wrong with my laptop

I rebooted the laptop. Always gotta turn it off and back on again. Unfortunantely, the same things happened.

Hypothesis 1.1: Something was wrong with an fstab entry

The first step was to look at the odd error out: the timeout to mount a disk. I looked up the UUID and found that it was an entry in fstab that tried to mount an external volume as ntfs, but it did have nofail specified so the failure to mount shouldn't be an error during boot. This entry had been working for months, so I didn't see why it would be a problem now. Nevertheless I added x-systemd.device-timeout=1 to the mount options and rebooted. Mounting the disk timed out quickly during boot now, and didn't cause any further issues. I guess the reason I never noticed that message before was that it does not affect graphical boot at all, and just quietly timed out after 90 seconds in the background.

This left the long wait for the network to come up during boot, and the failure to connect to the Wi-Fi.

Hypothesis 1.2: Something was wrong with my laptop's network ability

These two remaining problems were obviously tied together: Network manager waited during boot until the network was up, but because it kept trying unsuccessfully to connect to the Wi-Fi it took it until some timeout to bring the network up once it realized that it couldn't connect to the Wi-Fi. Since I'm not running a network-critical server with my laptop, I ran sudo systemctl disable NetworkManager-wait-online.service and turned off the boot delay. I don't need network capability to start my laptop, network manager can connect later, even after I'm logged in.

Now I was down to one problem: my laptop couldn't connect to the Wi-Fi.

Hypothesis 1.2.1: Something was wrong with my laptop's Wi-Fi radio

One of my fears was that I'd damaged my antenna or radio card somehow. To test this, I turned on my phone's hotspot and tried to connect with my laptop. Success. While this didn't entirely rule out my laptop as the problem, it did indicate the issue lay elsewhere.

When I turned my phone's hotspot off, it failed to connect back to the Wi-Fi. Now I was getting somewhere.

Hypothesis 2: Something was wrong with the router

The router was a Verizon FiOS-G1100.

This hypothesis seemed most reasonable now that I had two devices failing to connect. Other people in the house were still using the Wi-Fi, however, with no issues. One key to this hypothesis is that there were far more people on the WAP than normal: nearly a dozen people on the same Wi-Fi, each with their phones, laptops, tablets, etc. I would expect to see unusual failure under these relatively unusual conditions.

Eventually I was able to reboot the router, expecting that to fix the issue. The problem persisted.

I decided to try using a static IP address on my phone instead of using DHCP. It connected to the network with full internet access.

Hypothesis 2.1: Something was wrong with the router DHCP server

Using a static IP address on my laptop solved that connection issue as well. Clearly, there was something wrong with the DHCP server.

When someone noticed that the Roku TV wouldn't connect to the Wi-Fi, I tried to assign it a static IP address as well, but Roku only supports DHCP IP assigning. It was time to fix the router.

Hypothesis 2.1.1: Too many DHCP assignments

My working hypothesis was that somehow the amount of people on the network had run out of IP assignments. I couldn't find evidence in the router console of too many outstanding leases, but I wanted to try resetting the DHCP server anyway, guessing that the outstanding leases were hidden and only the current devices were being show.

There was no simple option to reset the DHCP server. Instead, I changed the IP assignment and gateway range from 192.168.1.x to 192.168.2.x, about which the console helpfully provided a warning saying it would require all devices to be assigned a new IP. Perfect.

As soon as I hit apply, the problems vanished. I re-enabled using DHCP on my phone and laptop, and they connected perfectly. The Roku TV connected, as did every other device in the house.

I still don't know exactly what went wrong, but I've got more experience for next time I run into this kind of problem. Plus, being able to fix it was kinda fun!

Autodrive into a crater fix

Wed, 08 Feb 2023 12:00:00 +0000

In my current Cataclysm: Dark Days Ahead playthrough, I ran into a problem with the autodrive feature: it'd drive me straight into a crater and crash the vehicle.

This seemed like a straightforward fix, so I checked out the master branch and set about debugging. Autodrive definitely has the capability to avoid certain terrain, so I guessed it was just a mistake in how it was calculating ledge traps or open air terrain.

Sure enough, it was just an error in how the vehicle was being considered as "able to drive over air". With the existing logic, autodrive thought every vehicle could fly. The fix was simple: only consider helicopters (the only flying vehicle) that have enough rotor power as flyable.

I have a pull request fixing this issue ready to be merged.