Windows sucks quite a bit on old systems, and I'd like to get it running a Minecraft server ahead of the 10th BosaikNet Anniversary on February 1st. Naturally, the answer is Linux. I picked Debian 12 (Bookworm) since I have the most experience in it, and for no other reason. The install process wasn't as smooth as I would have liked it to be since the graphical installer had a tendency to freeze. The Internet suggested this was due to either my use of a PS/2 keyboard or whatever internal components the PS/2 keyboard attached to within the PC. The text installer still works, and that installer ran just fine.
Since this is considered low-performance hardware, I used the LXQt desktop environment. After getting myself proper sudo permissions, hardening ssh (even though this isn't an Internet-facing machine anymore, it's a good practice to do anyways), and setting up ufw, I next wanted to replace the nouveau display driver with the non-free Nvidia driver to bring performance up as much as possible. The GT730 is not compatible with mainline drivers, and requires the nvidia-tesla-470-driver package. Installing this failed without telling me why, and I was left with a bunch of errors in dmesg upon rebooting (and a low-res display due to the VESA driver being used). Going against medical advice, I tried installing Nvidia's driver installation tool in hopes that it would tell me more and tell me quickly. After purging the last remnants of the Debian-provided driver to clear out errors with Nvidia's installer, I was told that kernel headers were missing. The package name for that was linux-headers-6.1.0-30-amd64, and this
should be provided by linux-headers-amd64. Installing that package made the installation succeed, then promptly crash the system for some reason. Either way, I no longer needed Nvidia's tool, and I could start again with Debian's provided package. This time, everything worked, and I rebooted to a crisp, responsive display.
Not long after getting everything running, I lost Ethernet connectivity, and I began seeing a stream of "e1000e enp4s0: Detected Hardware Unit Hang". These did not self-resolve after ten minutes. Some tweaks to flags via ethtool were recommended but did not fix the problem, although it may have delayed them. Ultimately I came across
a discussion of ASPM being at fault, which is a bit of a nuclear option but pointed me in the right direction. This eventually lead to
another discussion, whose answer cites Intel's driver notes that discuss earlier iterations of the 82573V (alongside the 82573L and 82573E) contained a flag in EEPROM that told the e1000 (Intel PRO/1000) driver that the device supports PCIe ASPM despite the feature being inoperative; later iterations remove the flag without correcting ASPM functionality. A
script was provided by Intel to correct this flag on systems where the flag is erroneously set, such as mine. After a reboot, Ethernet has been stable.
The BIOS seems to like to run the fans in a not-very-intuitive manner. A quick trip through lm_sensors's utilities sensors-detect and pwmconfig made for a simple fix to this. First, I enabled speed control of the chassis/system fans in BIOS (disabling this runs the fans at full speed, which on modern fans is not a bad option). I ran through sensors-detect first, which found my LM96000 chip. A reboot brought the sensors online, as starting kmod didn't for some reason. pwmconfig provides a setup wizard, which was rather straightforward: CPU fan1 could not be controlled (I'd expect it to be on hwmon0/pwm1), fan2 is unplugged, fan3 runs what I believe is the exhaust fan, and fan4 runs both of my intake fans. Unfortunately, hwmon0/pwm3 runs all three chassis fans (one exhaust, two intake), so I do not have independent control of those. I'm okay with that, since my only goal was to be able to set all of those fans to full speed. These case fans are not very loud, do not move very much air, and the Pentium D puts out quite a bit of heat when it is under full load. The old-style top-intake CPU fan also causes exhaust air to be re-ingested by the CPU fan in a front-to-back airflow design used in most modern cases, so the chassis temperature also tends to rise more than it should. Airflow is good, and it is keeping temperatures sane; under full load for an hour, I'm seeing 57C CPU, 43C northbridge, and 33C chassis. Tcase is a measly 63.5C for the Pentium D 945, and for a 130W chip that's not a huge margin for cooling. I'm okay with the current arrangement, but a tower cooler for the CPU is planned.
I tried using CoolerControl. It looks like a slick little application and it cooperates well with my LM96000 thanks to lm_sensors being awesome, but it freezes when I open the GUI. I need to talk with the nerds about that. For now, I don't need it.
Rebooting is still a chore. Occasionally, it fails to reboot, and does not make it to the POST screen. On one occasion, it hung at POST code 0, which shouldn't happen according to the
motherboard's technical manual shouldn't happen. Success rate seems to be around 50%. At this point I don't know if it's a power supply problem, a BIOS bug, or something with the graphics card. My intuition says BIOS bug, but maybe other factors are at play. Who knows?
The Minecraft client runs about 24 FPS, depending strongly at what I'm looking at. This is a big improvement over the Windows implementation. The internal server holds about 18 TPS, which is better than I expected for a purely CPU-bound task. Once OpenJDK is compiled, which I'm anticipating to take at least overnight, I'll let you know how Minecraft 1.21.4 PaperMC runs.