I've owned a Beelink U55 mini-PC since 2020, and I use it to run my homelab services. It's a nice little machine, quiet, low-power, and generally reliable for light workloads. But over the years, I've run into strange, unexplained crashes whenever the system is under heavy load, especially when running any sort of machine learning or image processing.

Here I document how I finally solved the issue, after a lot of debugging, trial-and-error, and help.

Background: Crashes With Photoprism and Immich

A while back, when I imported photos into Photoprism, the U55 would sometimes completely lock up and require rebooting. Photoprism uses machine-learning models to index and classify photos, so I always suspected it was related to those heavier tasks.

More recently I switched to Immich, which generally ran perfectly fine until I enabled the new OCR (Optical Character Recognition) feature. Running OCR over ~20,000 images caused the machine to consistently hard-crash after 1–2 hours.

This wasn't a normal crash:

• No SSH
• No kernel panic message
• No logs in journalctl
• Required a physical power-cycle

Sometimes a corrupted crash trace appeared on the HDMI output

I ran memtests, CPU stress tests, disk tests, everything passed. Only machine-learning style processing caused catastrophic failure.

Symptom: Completely Freezing Under Heavy ML/OCR Workloads

When Immich ran OCR, I regularly saw strange Linux kernel messages like:

BUG: unable to handle page fault
BUG: Bad page state
__rmqueue_pcplist
alloc_pages_mpol
do_anonymous_page

These are deep internal memory-management errors, not normal, and usually not software bugs.

Even stranger: sometimes the entire log stream just stopped, meaning the kernel froze so hard it couldn't even write to disk.

This told me the problem was:

• Not bad RAM (memtest was fine)
• Not a corrupt OS install
• Not CPU overheating
• Not Docker or Immich itself

It had to be something inside the kernel, or firmware (BIOS), or hardware DMA (like the GPU or USB/NVMe controller).

Initial Suspicions: Memory? Disk? GPU?

At first I considered:

• RAM issues → passed memtest
• Transparent Huge Pages (THP) → can stress Linux memory allocator
• NVMe or USB drivers → possible but unlikely
• Intel integrated graphics (iGPU) → shares system RAM, known to cause issues on older Broadwell systems
• Old BIOS → mine was from 2019

The early crash logs pointed to the Linux memory allocator failing in places that usually only fail if something scribbles over memory that it shouldn't.

That "something" is often a driver.

Since the U55 uses an old Intel Broadwell iGPU, and the iGPU shares system memory through DMA, the i915 driver became the #1 suspect.

Systematic Testing: Narrowing It Down

One by one, I tested each subsystem:

1. Disable Transparent Huge Pages (THP):
   In /etc/default/grub I changed the command:

   GRUB_CMDLINE_LINUX_DEFAULT="quiet splash transparent_hugepage=never"

   Helped slightly but did not stop crashes.
2. Disable i915 modesetting (i915.modeset=0):
   Still crashed, because this does not fully disable the GPU driver.
3. Fully blacklist the i915 driver:
   This prevents the GPU driver from loading at all:

   echo "blacklist i915" | sudo tee /etc/modprobe.d/blacklist-i915.conf
   sudo update-initramfs -u
   sudo reboot

   Suddenly the system became completely stable.
   Immich OCR ran for hours with zero issues.
4. Manually reload i915 (modprobe i915):
   After reloading the driver, the system crashed again within ~2 hours.

For sure the problem was the i915 driver.

BIOS Update? I Asked Beelink

I provided Beelink support with the serial number, model number and current BIOS version of the machine. Unfortunately they responded that my BIOS version is the latest, so there is no newer BIOS that fixes the iGPU issues.

Final Solution: Fully Disable the iGPU Driver

Since this is a headless server, the iGPU isn't strictly needed. You could use the iGPU to do hardware encoding/decoding of images and videos, but this iGPU isn't really powerful enough to make a meaningful impact.

The permanent fix:

1. Blacklist the i915 driver

echo "blacklist i915" | sudo tee /etc/modprobe.d/blacklist-i915.conf
sudo update-initramfs -u
sudo reboot

2. Keep THP disabled (smaller memory fragmentation)

transparent_hugepage=never

in GRUB or sysfs.

3. Leave Immich running CPU-only OCR

This is perfectly fine for a headless server.

Result: Completely Stable Under Heavy Load

With i915 fully blacklisted and THP off, the Beelink U55:

• processed all 20,000 OCR images,
• remained stable for many hours,
• produced no further allocator errors,
• exhibited no freezes, oopses, or page faults.

The machine is now reliable for heavy workloads.