Earlier this summer I built a new home server using an ASRock AM1B-ITX motherboard and a AMD Kabini Sempron 3850 CPU.
To make a long story short, this motherboard doesn’t work well for my intended use as a headless Linux server. The problems are manifold and interconnected:
- If I boot headless, it decides the integrated GPU isn’t being used.
- Once it decides the integrated GPU isn’t being used, it tries to use a PCI Express GPU, which it doesn’t find.
- At some point, it also reactivates compatibility mode.
- With compatibility mode activated it is, ironically, incompatible with my combination of hardware.
- The combination of all of the above means that it won’t boot headless.
These issues weren’t immediately obvious. The storage issues showed up early on, once I added the extra drives, but others took longer to show their face because, while I’ve been using it for its intended purpose for a couple of weeks now, I only just finally got around to moving it off the corner of my desk and into its final position on a shelf in a closet. I assumed this move would be relatively uneventful. It wasn’t, it was frustrating and tedious.
By way of context, I thought I’d give a few more details on my installation.
The system drive is a 256gb Crucial MX100 SSD. The root volume is relatively small, like 8GB or so. There is a small swap partition, an EFI partition, a good chunk of unused space as a lazy sort of SSD over-provisioning for longer life, but the bulk of the drive is set aside as for SSD caching of various volumes using Bcache. The root volume is un-exotic though, straight ext4. I’d intially set the system up to boot using legacy BIOS, but after some backflips, managed to convert it to use gpt partitions, and UEFI booting.
The SSD is connected to the main SATA3 controller on the Kabini SoC, as is a 3TB Western Digital Red drive. There are two other motherboard SATA3 ports provided by an ASMedia chip. These are attatched to 3TB and 1TB WD Green drives. None of this is very exotic.
The CPU/Motherboard has integrated video, which I had attached over DVI to an external monitor. The machine is intended to run headless, but I want to run some OpenCL stuff on the GPU, so I had to install video card drivers. By default, the system installed the open source radeon driver, but, from what I could tell, this doesn’t yet have OpenCL support, so I switched to the proprietary binary flgrx driver.
With that background out of the way, I’ll detail the many annoyances I’ve had with this system.
First off, I found that it would often boot slowly, or hang all together, and this tended to involve drives connected to the ASMedia SATA controller. Sometimes it would hang or take forever to detect connected drives. Other times, it would hang on the main BIOS screen, while lighting an activity light on one of those drives. After some trial and error, I figured out it worked much better if I disabled “Compatibility Support Mode” (CSM) in the boot section of the BIOS setup.
The next problem came when I shut the machine down, detached it, and moved the machine to its final location. When I rebooted it, it emitted 5 sharp beeps and then didn’t seem to do much of anything else, except light up the activity light on one of the drives connected to the ASMedia controller. I tried leaving it for a while, to see if it proceeded to boot, but finally gave up and tried resetting it. That didn’t work either, no beeps this time, but it still seemed to hang with the drive light activated. I moved it back to the desk, hooked up the monitor and tried to figure out what had gone wrong.
I found that the BIOS seemed to have reverted back to compatibility mode, moreover, the primary GPU was listed as being PCI Express, rather than integrated. A little digging and I learned that the 5 beeps meant “without vga card.” I mucked around a bit more, trying different things, before reaching the conclusion that this board has major problems, at least for my application.
I’m not sure what I’m going to do next. I realize it might be worth disabling the boot recovery mode, because that may be part of the reason it is falling back to a problematic BIOS configuration. My guess is that I may still have trouble with the internal video, but I might be able to address that with an explicit kernel option (assuming that the boot process still continues). Another option is to see if I can hook something to one of video ports that tricks it into thinking a monitor is connected.
