The musings and important information storage shed of Matt Kulka. I'll write about quirky things about Gentoo, Solaris and probably even Mac OS X or things dealing with systems administration in general as I encounter them at my daily job or in my limited free-time. Yes, even some Apple fanboyism too!

Search

Blog Roll

July 2010
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

XML Feeds

SASsy lip from the LSI 1068e

Are you a poor soul with a SuperMicro server that uses a X7DCL-3 motherboard with LSI 1068e SAS/SATA controller? HEY, ME TOO!@#

Much to my chagrin, a pile of these servers ended up in my hands and of course, I have to make them work. The problem being is that the stock Linux kernel (2.6.25) does not work with this controller in the state that I received them in. You can fiddle with BIOS settings all you like but it will do no good. Linux will laugh at you and take no pity. You have to get down and dirty with it.

The X7DCL-3 mainboard has a trusty jumper on it. Why it absolutely had to be a jumper and not some BIOS setting is beyond my electrical engineer skills, but opening the jumper in question (JPA2) will turn the controller from a "Software RAID" controller (the default setting) into an actual LSI 1068e JBOD controller (they call this mode "IT RAID", I'll assume this means "intelligent technician"). Allowing you to do things like: actually use it. Linux will then recognize the controller and attached drives with the stock Fusion MPT SAS driver.

But the fun doesn't stop there, no no no! You see because although the controller is there and seeing your drives, the MB BIOS won't actually give you the opportunity to boot from those drives until you upgrade the SAS controller firmware and BIOS. I'll save you the suspense and let you know where you can get the flash: ftp://ftp.supermicro.com/driver/SAS/LSI/1064_1068/IT/Firmware/B3/1.24.05/L8i/. Long story short, once you flash the controller, an entirely new SAS BIOS initialization routine is done during boot and voila, the BIOS can now boot from the controller. No strings attached, just some manual non-scriptable labor.

I didn't realize that so many people were willing to put up shoddy pseudo-hardware/software RAID devices to actually give the manufacturers balls enough to put out junk like this and still sell units. Likely, the people actually setting up and living with the hardware didn't order it themselves. The plight of being a low man on the totem pole. :(

Lastly, from what I've been experiencing so far. This controller looks to suck pretty bad under load in this state. An md RAID 0 rebuild is struggling to get better than 30MB/s and the system isn't the most snappy responding thing if I do something that requires a disk read. My recommendation is stay away from these things like the plague. But if you're stuck with them, it's at least possible to finagle it into working.

posted by Matt | 01/14/09 | 01:57:10 am | 24234 views | Hastily filed in Gentoo
PermalinkPermalink7 comments »Send a trackback »

0101010101001010101110101010101011100101010101010100111000111010101011100001010101010101101101010111000110101011001011110101010100101000111010101001110101010101010111101010111011010101001001111011011010011011111010111101001011011101010001110010101010100011110101010101111010101100010010101

Trackback address for this post

Trackback URL (right click and copy shortcut/link location)

7 comments

Comment from: Mick Russom [Visitor] Email
Thank you! Emails to vendor and Supermicro sit unanswered and your page got me going right away.

LSI and Adaptec both pull these JERK OFF stunts on these ASICs that have a HW-RAID capability but (Dell/HP/Supermicro/IBM) want you to buy a RAID-KEY to enable all the secret sauce.

I miss the days of simple SCSI controllers and simple SCSI-RAID controllers.

I really wish that all onboard devices would be JBOD only, these unlock the secret hardware raid things are always like this, and the super-killer is:

Why in the name of all things holy would LSI and Adaptec want to support this festering mess and miasma of all these different ways of doing the same exact ASIC? One guy embeds a SCSI-BIOS or SAS-BIOS within the main BIOS, another makes a discreet flash chip, the next does something else, and then, I compared the LSI 1068E firmwares between:

Sun/HP/Dell/IBM/Supermicro. I downloaded them all, and then compared.

For a single ASIC-revision, every frigging clown company has a different FW and BIOS revision! No one keeps these up to date, and nobody cares, and if you call LSI, they say, call the (insert Integrator Name Here) call the system integrator, and if they even (in the case of Supermicro) acknowledge your existence, or in the case of others even know what you are talking about they laugh off your request. You ask, hey, why is IBM's MPT-IT firmware for the SAME ASIC(Rev) ahead of yours, can you update yours to the latest? They can't even answer it. Its sloppy and disgusting and disorganized and wrong, and its LSI and Adaptec's fault. Imagine, engineers at LSI and Adaptec busy fixing errata but only the retail cards get the fixes and the myriad of OEMs integrating this stuff half-assed-ly don't even bother with the new firmware.

Its gotten to be a sad state of affairs.

On another system, I found a Supermicro SAS-RAID card that can be cross flashed with the retail SAS (8888ELP) firmware, and that is so much better. It was like version 6, dated in early 2007, and the retail SAS-RAID firmware and BIOS are on LSI's website are new, and if you saw the bugs that LSI fixes, you would know that you want to at least be aware of the errata that affects your SAS JBOD or SAS RAID controller.

I know this is all about fitting 15lbs of stuff in 5lb bags, making money off of RAID keys that re-enable purposely disabled features of an ASIC because marketing people suck and are stupid and cause everyone pain to make $50 bucks (just charge us $50 more and stop being jerks, OEMS) and all that…. But seriously, "COME ON."

I've always been into retail cards for systems builds, and have routinely been annoyed by half-assed or improperly done integrations of cards and ASICs you know are the same as the retail cards, but the vendor is either lazy, stupid, reckless or all three and simply chooses to suck.

Now if you work for a big huge company, they can be bent to your will, but if you are a SMB little guy little fry, which probably makes up a lot of these clown's business, you get treated like crap.
01/24/09 @ 00:23
Comment from: Matt [Member] Email · http://www.lqx.net
Glad to know that the post helped somebody! :)

The reason I got thrown these mostly is because even at the vendor level, SCSI is on its way out. That is a tragic thing as SCSI is rock solid and when there's a drive failure you know it. SATA on the other hand can hose up a system pretty well before you figure out something is funky with the drive and from my experience, results in a far more laggy system under load. Could just be the drivers, but SCSI controllers for the most part have been a pleasure to work with. Far more than I can say for SATA/SAS.
01/24/09 @ 08:37
Comment from: Mick Russom [Visitor]
Also, you can compiled the ITE driver for the kernel yourself. This damn motherboard has some sort of off brand IDE controller for the DVD.

The sources are on supermicro's website, I'll post a howto here later.
02/17/09 @ 14:10
Comment from: Brian [Visitor]
Thanks Matt! I was having much the same trouble on an X8DT3-F when I found your blog. With your instructions I was able to install and boot off SAS attached disks.

One note, Supermicro does have new drivers on the site than the link above. The BIOS of the newer packages failed but the firmware failed a checksum. Using Matt's link above caused no problems.

Brian
06/29/09 @ 12:36
Comment from: Yestine [Visitor]
After much trouble trying to install Ubuntu 8.04 LTS, Ubuntu 9.04, CentOS 5.3 and failing miserably each time, I finally found this post which suggests a direction to head in.

However, after flashing the BIOS, both the LSI controller (in IT RAID mode) and Ubuntu installer (using mptsas) are unable to detect the presence of any drives. I'm using 4x1TB SATA hard disks so is there a problem with the controller not being able to support such huge sizes?
09/07/09 @ 20:54
Comment from: Joe "Floid" Kanowitz [Visitor]
@Yestine: More than a little late, but having just noticed you in the comments here - if you run into this with a LSI 106x-family product, try forcing your disks to 1.5Gbps / "SATA 150" [on SATA devices, normally requires a DOS utility from the disk vendor] or vice-versa.

IIRC most newer firmwares for these controllers force one rate (the slower one?) with SATA because some unknown devices weren't negotiating properly, while most SATA disks now ship forcing the *other* rate for similar reasons. Situation normal. Unfortunately I can't find the reference now to confirm (and make sure I'm not backwards on the rates).
02/09/10 @ 18:06
Comment from: Marcin [Visitor] Email
Hi,
I have bought similar motherboard with the same controller. That link is broken maybe you know where i can get that. I tried to contact supermicro.com but they can't give me that :[
Best Regards,
Marcin
05/26/10 @ 11:16

Leave a comment


Your email address will not be revealed on this site.

Your URL will be displayed.
(Line breaks become <br />)
(Name, email & website)
(Allow users to contact you through a message form (your email will not be revealed.)

bottom corner