Supermicro PDSMi+ BIOS bugs — part 2

After a bit of arguing with Supermicro, who was supposedly unable to reproduce the problem on many different brands of USB flash drives, I eventually gave in and mailed them both my SanDisk and my Kingston drives.

I received a mail late this week stating the following:

I’ve just received your two USB flash drives in the morning and we do see the issues you claimed.

I am seeing the only difference between yours and mine is the some code at the back of the flash drive (maybe a date code).

We’ll try to figure out the reason and keep you posted.

The “some code at the back of the flash drive” I have to assume is a model number or production date physically printed on the flash drive casing, and not “code” as in binary data at the end of the flash segment on the drive itself.

I really hope Supermicro figures this out, and just as important, I hope they start taking my bug reports a little more seriously in the future.

VHScrCap bugs

Many months ago, I found an incredibly annoying bug in a DirectShow filter/capture driver called VHScrCap, both in the older 1.x versions, as well as the newer 2.x versions.

Before I go into the bug, I’ll explain what VHScrCap is and what purpose it serves. It’s a very popular application used for capturing portions of one’s desktop (or any application window) and retransmitting it to any WDM-compliant (thus DirectShow) capturing application. For example, if you’re on Windows Live Messenger and want to show your friend a portion of your Firefox window, you can use VHScrCap for that purpose. The VHScrCap driver shows up as a webcam device in applications which support DirectShow — including Adobe Flash. VHScrCap is also quite fast, including some optimisation features which make it significantly fast even with large regions (1920×1200 for example).

For a few years I’d been using VHScrCap for one purpose: capturing the video portion of a Windows Media Player or Media Player Classic window, and re-streaming the video to a friend of mine in Michigan via Ustream. We watch bi-weekly episodes of Game Center CX, the Angry Video Game Nerd, island survival adventures involving members of Yoiko, or even us playing video games. Ustream uses Adobe Flash as a client (on both the sender and receiver side).

The bug was simple to reproduce: launch Ustream, launch VHScrCap’s configuration utility, set things up, and stream something as usual. Once finished, exit the browser, then go through the same routine again. The capture region/aspect ratio was completely wrong, and in some cases the capture region was capturing something like an 8×8 pixel region on my screen (and was heavily blurred at that!). I’ll add that the issue was not specific to Ustream: I could use Windows Live Messenger, or any DirectShow-friendly application to reproduce the bug.

I found that deleting the registry key HKLM\Software\HmelyoffLabs\VHScrCap before launching Ustream would fix the problem every time. Actually, to be more specific, deleting HKLM\Software\HmelyoffLabs\VHScrCap\params is what would fix it. I ended up writing a batch file and a replacement .reg file to work around the problem. See below for the link to those.

In December I contacted VHScrCap’s author and informed him of said bug, attaching screenshots of the problem. At first the author blamed Adobe Flash for the problem, and insisted I send him mini memory dumps when the problem happened (which required me to install extra Microsoft software). So I did. Then the author insisted there were no bugs in his code, and asked me to capture video of said problem. So I did. The author continued to blame Adobe Flash for something that is quite specific to his driver. I offered to completely format and reinstall Windows XP on my workstation as a form of troubleshooting — it made no difference. I eventually gave up communicating with the author, as it became obvious from the tone of his mails that he had zero interest in fixing this bug.

In case you want the workaround batch + .reg file, or to see the videos of the problem, they’re available below. Keep in mind that the .reg file is specific to VHScrCap 2.1.2 and will not work with earlier versions or later versions.

http://www.malkavian.com/~jdc/vhscrcap/

And then something happened yesterday…

I came across a Japanese application called SCFH DSF (which is a DirectShow Filter version of the SCFH program). You see, a few months back, the same friend and I translated SCFH and made an English version of the binary for personal use (I can’t/won’t post it out of respect for the author — I need to get in contact with him so there can be an official English release!). But a few weeks ago, the author released a DirectShow Filter version of his program, which means it more or less does the same thing VHScrCap does!

I promptly uninstalled VHScrCap and installed SCFH DSF. The client is in Japanese (I’m working on an English version), but it works wonderfully. Does it have the same bug as VHScrCap? Nope! Which further proves that the problem is with VHScrCap…

So for any visitors which use VHScrCap, reconsider using a DirectShow filter that actually works. :-)

Amusing death of the week.

Just happened a few minutes ago…

1 1498318 koitsu-Val-Hum-Mal-Law choked on his food in Gehennom on level 42 [max 48]. Choked on a fortune cookie. 245 [245]

I should have been paying more attention to the word “Satiated”. ;)

LiveJournal feed

A friend of mine has stuck a RSS feed thingus up on his LiveJournal account, which references my Blog here on wordpress.com.

http://syndicated.livejournal.com/koitsu_blog/

If you’re a LiveJournal user, you may appreciate the use of that, rather than having to visit this site.  :-)

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).

Voila! 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:

Jeremy,

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:

http://www.gamebeat.net/forum/showthread.php?t=1057

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:

Jeremy.

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

<removed>

—–Original Message—–
From: <removed>
Sent: Thursday, April 03, 2008 4:06 PM
To: <removed>

<removed>,

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 <removed>’s team to troubleshoot the problem.

<removed>
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.