My First DIY NAS Build: Troubleshooting the Supermicro X10SLL-F + Intel Pentium G3258

CPU: Intel Pentium G3258
Motherboard: Supermicro X10SLL-F (~$170,
Memory: 2*8GB Crucial DDR3-1600 1.35v DR x8 ECC UDIMM 240 pin, CT2CP102472BD160B (~$170,
Case: Fractal Design Define R4 Blackout Edition
PSU: Corsair CS450M 450W Modular

I encountered problems soon as the build was completed. IPMI showed that the system was addressable, but I couldn’t read any values from the sensors (all sensors displayed N/A). No video output from either the onboard VGA or through an add-on video card. No beep codes from the motherboard to report.

I spoke with Supermicro technical support to learn that my board was shipped with BIOS revision 1.1. At the time that the Supermicro X10 series was released, the selection of Intel LGA1150 processors was more limited than it is now. The Intel G3258 is a Haswell Refresh (aka Devil’s Canyon) processor, so it was possible that changes (to the microcode?) broke compatibility with the Supermicro X10SLL-F. The newest BIOS revision 2.0 is X10SLL4.424, which was released on April 24, 2014.

I had two options available to flash the BIOS myself. The two options for flashing a Supermicro motherboard have been written about at length (see Bhargav’s IT Playground – update BIOS on Supermicro Servers with DOS bootable), so I’ll only share some questions and answers that I got from talking with Supermicro technical support staff.

My first conversation with Supermicro technical support led me to believe that it was possible to flash the X10SLL-F without a CPU installed. The guy on the line told me that I could purchase Supermicro SFT-OOB-LIC, a ~$20 license that enables an administrator to flash the BIOS through IPMI. I weighed my options. I could:

  1. Remove the Supermicro X10SLL-F from its case, package it, and ship it to Supermicro for them to update the BIOS
  2. This option has a turnaround time of one week, but it has a low dollar outlay (not accounting for time spent removing, packaging, shipping, and reinstalling the motherboard)

  3. Flash the BIOS through IPMI after purchasing Supermicro SFT-OOB-LIC for $20
  4. This option would get me up and running in the least amount of time, provided that the compatibility issue was only in the BIOS

  5. Take my NAS box over to Microcenter, ‘borrow’ a processor from them, flash the BIOS, and return the CPU
  6. The most unattractive option in terms of time and ethics. If I can avoid two roundtrips and forcing a retailer to sell back an item as an Open Box Item, then I would like to avoid it

I decided that flashing the BIOS through IPMI would be the best option given the circumstances. I was prepared to make the purchase of the license, but then I thought that I had better call Supermicro technical support to be sure that the IPMI BIOS update would work as I expected. A new voice greeted me on the other side of the line. When I explained what I was about to do, the man told me that this wasn’t possible. How could I flash a BIOS without a working CPU installed, he asked?

I looked at the time and decided that I had best get myself over to Microcenter. I brought my NAS with me and took it into Microcenter’s technical support department. The man working that department greeted me: I explained my situation, and he told me that I could use the room.

The Houston Microcenter has a modest selection of current-generation processors. The only one that I was confident would fit my billing was an Intel Xeon E3-1240 v3 (Intel), which I picked up for $249.99 BTAX. It was released in Q2’13, sufficiently long ago that there shouldn’t have been any compatibility issues arising from the X10SLL-F’s BIOS.

Back in the room, I opened up my MacBook Air and fired up Windows 7. I created a bootable USB flash drive using Rufus (Rufus – create bootable USB drives the easy way, free download) and copied over the files from X10SLL4_424.ZIP. I swapped out my Intel G3258 for the new Xeon E3-1240 v3, plugged in the USB drive, and booted up the NAS box.

Unfortunately, flashing the BIOS didn’t fix the issues that I had. The Intel G3258 still wouldn’t POST. I would have liked to stay and troubleshoot longer, but Microcenter was closing. I packed my things and headed home, determined to fix the problem at the start of the new day.

I swapped back to the Xeon E3-1240 v3 and went into the BIOS. It clearly showed revision 2.0, so what was going on? I ran the flash utility once more, hoping that I might gather some clues that I missed the first time.

Bingo — I saw two messages that had puzzled me the first time. AFUDOSU.EXE not found and Error when sending Enable Message to ME !!. Armed with this new information, I called Supermicro technical support once more.

I explained to the man on the line that I was encountering some issues with my X10 series motherboard. He listened for a while, and then stated that he’d try to get me in touch with the engineer that had been working on this particular board. I left a call-back number and waited.

I spoke with Milton Cai. He listened to my situation and then checked the Intel Pentium G3258 against the list of qualified processors for the X10SLL-F. It didn’t appear on the list.

Milton was kind enough to send over the list of qualified processors for the Supermicro X10SLL-F. I’m a little puzzled why Supermicro does not publish this list on their website, but it’s reproduced for you here.

Lesson learned: always consult the manufacturer of the motherboard to be sure of a processor’s compatibility before falling in love with a processor

FreeNAS: First Boot Issues

As of yesterday evening, I’ve gotten FreeNAS installed and running.

I ran into a couple of issues that I was able to find answers for.

run_interrupt_driven_hooks: still waiting after xxx seconds for xpt_config

This message came up the first time that I booted from my FreeNAS USB flash drive. I’d just started up the machine, set the boot devices in the BIOS, and watched a wall of text with various system information go flying past. Then I was left with this message:

run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config
run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config

I shut off the machine, waited, and turned it back on again. This time, it brought up a screen with:

F1 FreeBSD
F2 FreeBSD

Boot: F1 ###

A new # appeared every second, or every time that I pressed a key on the keyboard. I tried pressing F1, and the # marks stopped appearing. Below, a new line, and a blinking _ (underscore).

Pressing F6 brought up a new prompt, which advised me that I ought to insert some boot media.

Background: Missteps?

I wasn’t able to get back to the first error, run_interrupt_driven_hooks, after my first boot. After seeing the F1 FreeBSD, F2 FreeBSD screen a few times, I got frustrated and rewrote the contents of the FreeNAS .IMG to my USB flash drive once more. This got me back to square one, though it probably wasn’t necessary.

Solution to run_interrupt_driven_hooks

The solution was to disable the onboard 1394 controller in the BIOS.

On my ASRock 970 Extreme4, I enter the BIOS, navigate to the Advanced tab, enter the South Bridge Configuration, find Onboard 1394 controller, and set it to Disabled.

Solution to F1 FreeBSD, F2 FreeBSD, or FreeNAS not booting successfully from USB drive

I read that this was attributed to using a USB 3.0 port. Guidance here was to switch from the USB 3.0 port to a USB 2.0 port. Sure enough, I removed my flash drive from the USB 3.0 port that it had been plugged into, relocated it to a USB 2.0 port, and was able to get my FreeNAS box to boot to the administrator menu.

More updates on this subject to follow. Until then, I’m diving back into the FreeNAS documentation and playing with the system.