FIREBAT S1 hard freezes (Intel N150)

K

Kran

New Member
Aug 9, 2026
3
0
1
I own a FIREBAT S1 mini-PC with the following configuration:

CPU: Intel N150

RAM: 16 GB

Network: Realtek RTL8111/8168/8211/8411, rev. 15 [10ec:8168]

Network driver: r8169

I installed Proxmox VE on this mini-PC about a year ago. Unfortunately, I no longer recall exactly which version was used initially. Over the course of the year, the system was updated periodically and ran stably for a long time.

Problems began after one of the recent major updates and the switch to kernel 7.0.x.

Since then, Proxmox has started freezing completely. The server usually runs for a few hours before a hard freeze occurs. Sometimes it runs for up to 8 hours, while at other times it freezes much sooner.

The freeze manifests as more than just a loss of network connectivity:

SSH access is lost;

the local keyboard stops responding;

the Proxmox console becomes inaccessible;

sometimes the Proxmox Web GUI partially loads, but VMs/LXCs show an "unknown" status;

some web services already running inside LXCs may remain accessible for a while;

during one freeze, the Proxmox load average reached approximately 152;

in this state, a normal shutdown or reboot is impossible; the power must be cut.

I initially suspected the issue was caused by kernel 7.0, so I tested older kernels:

7.0.x

6.17.x

6.14.11-9-pve

However, the freezes occur on all of these kernels.

Subsequently, I completely reinstalled the server with a clean Proxmox VE 9.2 installation and restored the VMs/LXCs from backups. This did not help either—hard freezes continue to occur. So far, the following checks/actions have been performed:

verified operation on kernel 7.0.x;

verified operation on kernel 6.17.x;

verified operation on kernel 6.14.11-9-pve;

disabled PCIe ASPM using `pcie_aspm=off`;

disabled EEE on the Realtek NIC;

attempted disabling network offload functions;

disabled Wi-Fi;

installed and am using the latest `intel-microcode`;

current Intel N150 microcode revision: 0x1e (updated early from 0x1a);

separately tested booting with `nomodeset` to rule out Intel iGPU/i915 issues.

Latest test:

kernel 6.14.11-9-pve + `pcie_aspm=off` + `nomodeset`

After booting, i915/xe were not in use, and `/dev/dri/renderD128` was missing. Despite this, the server froze completely again.

Thus, disabling the iGPU/i915 did not solve the problem.

I am also concerned about the integrated Realtek RTL8111/8168 rev.15 [10ec:8168] network card. It is currently using the standard `r8169` driver. I have seen reports of issues with this Realtek series when using `r8169` and recommendations to try `r8168`, but I haven't changed the driver yet to avoid altering multiple parameters simultaneously.

At this point, I am considering several options:

replace `r8169` with `r8168`;

check the impact of CPU C-states/power management;

try Proxmox VE 8.4 with the stock kernel 6.8.12;

continue investigating the issue within the hardware/kernel. That said, prior to the updates, this same mini-PC ran stably on Proxmox for a long time; therefore, I suspect changes related to the kernel, drivers, or power management rather than a sudden hardware failure.

I would be very grateful if owners of the FIREBAT S1 / ACEMAGIC S1—or other mini-PCs based on the Intel N150—could share their experiences.

I am particularly interested in the following:

Which Proxmox and kernel versions are running stably for you on the Intel N150?

Have you encountered similar "hard freezes"?

Do you use the `r8169` or `r8168` driver for the Realtek RTL8168?

Have you had to disable C-states, ASPM, EEE, or other power management features?

Is it worth trying Proxmox VE 8.4 + kernel 6.8.12?

Are there any known issues with the Intel N150/Alder Lake-N that could cause this kind of behavior?

I would appreciate any suggestions regarding what additional logs or diagnostic information I should provide.
 
Before continuing down the PVE/kernel route, I'd validate the hardware. I've had a few of these small boxes and lost both SSDs and memory in them.

Your testing has ruled out a lot of the software side (though that's not to say there isn't a possible issue still).

Boot something like SystemRescue from a live USB [0] and:
- memtest overnight
- nvme smart-log /dev/nvme0 and nvme error-log /dev/nvme0
- nvme device-self-test /dev/nvme0 -s 2, then read nvme self-test-log

Also worth reseating the memory and storage.

[0] https://www.system-rescue.org/
 
  • Like
Reactions: ITT
No, the problem is with ProxyMox itself. I just installed version 8.4, and the server has been running fine for 24 hours now.
I'll try restoring some of my containers and monitor the system's stability.
I'll add: I checked the hard drive and RAM, and everything was fine. Note that the problem started appearing after my updates.
 
Other cause could be the m2 NVME SSD disk where the Proxmox located.
I have seen other systems in Sleep/PowerSaving mode the NVME SSD disk disappears/lost (hard freeze) cannot recover due there is no disk.

Options:
1., Try to disable powersaving in your m2 NVME SSD disk - in hardware ( not in kernel ):
Code: 
$> nvme list

# Check status #
$> nvme get-feature /dev/nvme0 -f 2 -H

# Disable PowerMangement #
$> nvme set-feature /dev/nvme0 -f 2 -v 0

# Limit PowerMangement - if disable not working #
$> nvme set-feature /dev/nvme0 -f 2 -v 2

2., Put the Proxmox OS to 2.5" SATA SSD
The m2 SSD specs has no "hot swap" function like the SAS/SATA SSD.
The SAS/SATA SSD when disappears in Sleep/PowerSaving Mode, they can recover.
The m2 SSD cannot recover, need to reboot - This is the case with direct pcie bus connection to the CPU, if you have PCIE-E (PLX/PEX) switch then maybe has "hot-swap" function - this hardware does not have it.
 
Last edited:
You must log in or register to reply here.
Top Bottom
Back