Just to add a bit to this, I just love sweeping generalizations... On 9 Jan 2011, at 19:33 , Richard Elling wrote:
> On Jan 9, 2011, at 4:19 PM, Edward Ned Harvey > <opensolarisisdeadlongliveopensola...@nedharvey.com> wrote: > >>> From: Pasi Kärkkäinen [mailto:pa...@iki.fi] >>> >>> Other OS's have had problems with the Broadcom NICs aswell.. >> >> Yes. The difference is, when I go to support.dell.com and punch in my >> service tag, I can download updated firmware and drivers for RHEL that (at >> least supposedly) solve the problem. I haven't tested it, but the dell >> support guy told me it has worked for RHEL users. There is nothing >> available to download for solaris. > > The drivers are written by Broadcom and are, AFAIK, closed source. > By going through Dell, you are going through a middle-man. For example, > > http://www.broadcom.com/support/ethernet_nic/netxtremeii10.php > > where you see the release of the Solaris drivers was at the same time > as Windows. > What Richard says is true. Broadcom have been a source of contention in the Linux world as well as the *BSD world due to the proprietary nature of their firmware. OpenSolaris/Solaris users are not the only ones who have complained about this. There's been much uproar in the FOSS community about Broadcom and their drivers. As a result, I've seen some pretty nasty hacks like people using the Windows drivers linked into their kernel - *gack* I forget all the gory details, but it was rather disgusting as I recall, bubblegum, bailing wire, duct tape and all. Dell and Red Hat aren't exactly a marriage made in heaven either. I've had problems getting support from both Dell and Red Hat, them pointing fingers at each other rather than solving the problem. Like most people, I've had to come up with my own work-arounds, like others with the Broadcom issue, using a "known quantity" NIC. When dealing with Dell as a corporate buyer, they have always made it quite clear that they are primarily a Windows platform. Linux, oh yes, we have that too... >> Also, the bcom is not the only problem on that server. After I added-on an >> intel network card and disabled the bcom, the weekly crashes stopped, but >> now it's ... I don't know ... once every 3 weeks with a slightly different >> mode of failure. This is yet again, rare enough that the system could very >> well pass a certification test, but not rare enough for me to feel >> comfortable putting into production as a primary mission critical server. I've never been particularly warm and fuzzy with Dell servers. They seem to like to change their chipsets slightly while a model is in production. This can cause all sorts of problems which are difficult to diagnose since an "identical" Dell system will have no problems, and it's mate will crash weekly. >> >> I really think there are only two ways in the world to engineer a good solid >> server: >> (a) Smoke your own crack. Systems engineering teams use the same systems >> that are sold to customers. > > This is rarely practical, not to mention that product development > is often not in the systems engineering organization. > >> or >> (b) Sell millions of 'em. So despite whether or not the engineering team >> uses them, you're still going to have sufficient mass to dedicate engineers >> to the purpose of post-sales bug solving. > > yes, indeed :-) > -- richard As for certified systems, It's my understanding that Nexenta themselves don't "certify" anything. They have systems which are recommended and supported by their network of VAR's. It just so happens that SuperMicro is one of the brands of choice, but even then one must adhere to a fairly tight HCL. The same holds true for Solaris/OpenSolaris with third-party hardware. SATA Controllers and multiplexers are also another example of the drivers being written by the manufacturer and Solaris/OpenSolaris are not a priority over Windows and Linux, in that order. Deviation from items which are not somewhat "plain vanilla" and are not listed on the HCL is just asking for trouble. Mike --- Michael Sullivan michael.p.sulli...@me.com http://www.kamiogi.net/ Mobile: +1-662-202-7716 US Phone: +1-561-283-2034 JP Phone: +81-50-5806-6242
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
