On Thu, 04 Mar 2010 19:47:38 -0500 Nick Holland <[email protected]> wrote:
> Tomas Bodzar wrote: > > You just think that it's running perfectly under Linux ;-) See eg. > > this post http://marc.info/?l=openbsd-misc&m=125783114503531&w=2 > > Think about this a bit. These people DELIBERATELY put a feature in > their firmware to STOP me (and a lot of other people) from using this > card. Legit user, but they felt that I was entitled to help them > debug their shit for no more than sixty days. They worked hard at > putting this feature in. This isn't a piece of software that has > access to the resources of a computer, like real-time clocks and > writable disks. This is a fucking RAID controller, which they managed > to build a persistent time bomb into so that after 60 days of > operation, it destroyed itself!! (and again, note: it didn't just > crash and need to be power cycled, it DAMAGED THE CARD). This took > some effort -- I can't think of any other reason to have a RTC in a > RAID card. I also somehow doubt that the coder who did this sat down > and wrote the time bomb AFTER he was charged with coming up with the > diagnostic firmware. No, I rather suspect he grabbed some > off-the-shelf code, something they put routinely into their diagnostic > and troubleshooting systems, but wasn't intended to get out into the > general public. They obviously care more about things OTHER than your > system integrity and reliability. This coder made an error in > judgment, but they obviously had the tools laying around for some > reason. > NOTE: A customer should never need to do this, but... For all intents and purposes, the card "damaged" itself per se by preventing itself from working, but with the right know-how, you could get it working again. The RTC of the card has to pull time from somewhere as well as keep time (i.e. needs power). If the card is not battery-backed, then it's drawing current from the mainboard. Yes, even when the system is supposedly in a "powered off" state. (If you read the PCI/PCIX/PCIE specs, you'll understand there is power available even in the "powered off" state to support features like "Wake-On-LAN"). If the card is battery-backed, then it could be drawing current from either the bus or the battery. None the less, no current, no clock. Remove the card, and remove the battery from the card if one is present. In case they have caps in place to handle short outages, short the battery leads and PCI power pins to drain them. Boot the system, set the clock back a month or whatever, then power it off again. Reinstall the card and you'll be able to get into it again to reflash with non-time-bombed firmware. Of course no sane human being would put up with needing to do crap like the above just to use the hardware they've paid for, but when you're stuck, you're stuck. > > Now, tell me again how horrible it is that OpenBSD doesn't let you > trust your data (and OpenBSD's reputation) to these incompetent > assholes? > Adaptec is actually far worse than they seems to normal end users and open source developers... I might get my happy ass sued into oblivion for posting the stuff I know, so I'll tell you a possibly fictitious story that was told to me by a friend. A number of humongous, deep pocket, mega corps decided to bring a new type of tech to market... QUIETLY! One of the requirements was testing said tech with *ALL* of the *BEST* storage cards and storage devices, which is nothing more than a pleasant way to say the unannounced stuff that doesn't officially exist yet. The CTO was told by said friend to not waste any time testing Adaptec, but was promptly told to shut up, since their "unannounced" gear had already been delivered, along with the personal cell phone number of the EVP from Adaptec in charge of storage products. Ya, the usual... There were "business connections" involved and "agreements" at the "highest levels," so plainly stating the obvious like saying "The Emperor has no clothes" was strictly verboten... Four weeks and multiple replacement cards later, they gave up trying to test Adaptec cards. The all failed. Miserably. The newest storage devices (various forms of "SSD's") caused everything from Adaptec to fail, even though there was nothing wrong with the storage devices. Of course they got the typical story from Adaptec of, "We've only qualified Intel SSD's with our products." --Bullshit. On inquiry, it turns out they never bothered to see what would happen if a *FULL* *SET* of (still unreleased) Intel SLC based 512GB SSD's was attached to their controller. Even a "minimal" set (no expansion backplanes) of the widely available Intel SSD's made their controller fail. It was pretty obvious that Adaptec hadn't tested their shit at all with SSD's of any type... Of course Adaptec claimed the problem was not their fault due to them using the newest unreleased "research" devices, but they were then duly informed of all the failed tests using the exact off-the-shelf Intel SSD's which Adaptec had supposedly "qualified" with their cards. If attempting to test the Adaptec hardware wasn't such a massive waste of time, effort, and money, it would have been hilarious. > It does bring one part of the OpenBSD stance on aac(4) into question, > though. The real reason they aren't giving us the errata for these > products may not be that they don't wish to or are embarrassed by how > bad it is, but that they don't even understand the problems in the > product themselves. > The answer is both. > Doesn't change the conclusion: Adaptec products > can't be trusted (though might be suitable for vmware servers). > If by chance you actually need a storage controller, Adaptec doesn't make them any more, and hasn't for the last decade. You're better off buying a less expensive door stop. jcr
