Supermicro PDSMi+ BIOS bugs

In our datacenter, we predominantly use Supermicro SuperServer 5015M-MT+ systems, which use Supermicro PDSMi+ motherboards. However, on all of these systems, I’ve never been able to boot a USB flash drive to perform BIOS upgrades — I’m always forced to use floppy disks, which is absolutely silly in this day and age.

Booting a Sandisk U3 Micro Cruzer 2GB flash drive results in the BIOS taking almost 3 full minutes to detect the drive during POST. Once the drive is detected, it prints out the drive model, then spends another 3 full minutes doing God-knows-what before booting the drive. Once booted (into MS-DOS), a DIR on the drive results in another 3 minutes of stalling before outputting a directory structure.

I’ve reproduced this problem on all PDSMi+ systems I’ve used, including the one I use at home (which isn’t a SuperServer; it’s just a PDSMI+ motherboard in an Antec case).

The BIOS version used doesn’t matter; the bug happens on v1.1, v1.2, and the latest v1.3.

I reported this problem to Supermicro Support, providing all necessary reproduction steps. Their first rebuttal was “Have you tried upgrading the BIOS to v1.3? We haven’t seen this happen on other” (I was using v1.2 at the time), so I upgraded — no difference. Their next response was:

Some USB key(s) don’t not response BIOS command normally and might have this problem. We had this kind of issue in BIOS developing and patched for some on hand. But we cannot cover all.

I then received another response from Support, demanding that I buy another USB drive, implying that Sandisk flash drives aren’t bootable (which is false, because I can boot said drive on my Asus and Giga-byte workstations without any issue).

I followed their advice regardless: I went out and bought a brand new Kingston DataTraveller 100 4GB USB drive (costing me US$24 from Amazon), followed a common procedure to make the drive bootable.

This drive behaved differently: the PDSMi+ BIOS would not detect it no matter what I did.

All of this proved one thing to me: the BIOS has at least one bug, quite possibly two.

So I did the most logical thing to test their claim: tried both the Sandisk and Kingston USB flash drives in a different model of Supermicro system. I tried them in a Superserver 5013C-T+ box (which uses a Supermicro P4SCE motherboard).

Voilà! It booted fine! No weird 2 minute stalls on the Sandisk, and the Kingston was completely recognised.

I reported all of this data back to Supermicro Support, who then responded with the following:


Would it be possible to send us one of your drives?

This REALLY pissed me off. Was he trying to tell me that Supermicro couldn’t afford to go out and buy a US$24 flash drive and confirm this problem themselves? I sent the following response:

Supermicro QA can’t afford a US$24 flash drive to reproduce this? If you want instructions on how I make bootable USB flash disks, I can provide step-by-step instructions (which are also on the Internet, so they’re commonly-used). It’s incredibly simple:

If you really are serious, I would be willing to send one to your San Jose office. If it “gets lost” while in Supermicro’s hands, it gets lost; I won’t be disheartened.

Just remember: the behaviour differs between the Kingston and the Sandisk — yet both boot/work fine on a 5013C-T+.

I woke up this morning to find the following mail from Support in my mailbox, which made me clench my fists:


The engineer is asking for your USB drive, please see below.

—–Original Message—–
From: {…}
Sent: Thursday, April 03, 2008 4:06 PM
To: {…}

Please reply to this customer and ask him to send us the USB bootable drive. We can make our own but we cannot be sure that we could duplicate problem with our USB drive. It’d be better to get his. Get the USB drive, duplicate the issue and if you see problem ask ‘s team to troubleshoot the problem.

Product Manager

It was then apparent to me that Supermicro does not bother to read mails sent from customers in full. Supermicro told me to go out and buy a brand new flash drive, so I did — and continued to have problems. So what’s stopping them from going out and buying the same drive and repeating the procedure I gave them? Nothing. Two different flash drive vendors, with two different (broken!) BIOS behaviours.

I’m absolutely baffled at the fact that they still think this isn’t a BIOS problem. I’ve done all of the work for them, yet they want my flash drives. This is such a bizarre method of diagnosis, and it’s entirely customer-unfriendly.