Date: Mon, 22 May 95 11:43:13 MDT From: terry@cs.weber.edu (Terry Lambert) To: henrich@crh.cl.msu.edu (Charles Henrich) Cc: freebsd-bugs@FreeBSD.org Subject: Re: MAJOR problem with FreeBSD-2.0-RELEASE Message-ID: <9505221743.AA14812@cs.weber.edu> In-Reply-To: <199505220315.UAA07572@freefall.cdrom.com> from "Charles Henrich" at May 21, 95 11:15:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Rod> I will not be pursuaded to change my stance on Bus Logic due to past Rod> record. There current record is horrible, and that is enough for me Rod> to pursuade people to seek alternatives, realize I sell these products, > Wait a minute, your telling me that because the support for the buslogic cards > are broken (when not two weeks ago it was the card suggested as the best and > most reliable by many on the freebsd-hackers lists) that we should buy > different cards instead of fixing the broken drivers? If this is how broken > drivers are handled (okay, dont use THAT one) FreeBSD has some serious > problems... Tell me Im misunderstanding something here, afterall I know I > chose FreeBSD over Linux primarily because I felt it was better supported with > a central core team and such. Is this not a true statement? Please provide some mechanism to indicate quoted material. I barely recognized the quoted text as coming from Rod. The problem is *not* the drivers. Let me explain this. A computer is like a car. We have a left front quarter panel from a 67 Mustang (the driver), only Buslogic has this year manufactured about 10 model years of cars, and not suprisingly, the panel doesn't fit all of them. We need about 5 panels. Basically, the Buslogic people have made many small design changes without an attempt at maintaining anything other than BIOS compatability between the boards. To correctly support the cards, the maintainer of the Buslogic driver would need one of each card delta to test with, and documentation of the card changes so that a diff can be done to provide a minimal set of replaceable components to cram these 5 drivers into a single driver. Needless to say, the people willing to take this work on have been refused the necessary information by denial-of-service from the support department -- the second thing that needs to change at that company is proper categorization of support requests. The first thing, of course, is that they need to apply responsible release engineering practices both to their board and ROM designs. In general, that means an 800 pound Gorilla with the ability to say "that doesn't ship". Unlikely for a company with less than two assembly lines, and I'm currently too busy to take the job for the next several months. Perhaps they can hire a consultant, since it's a process problem, not a personel problem, and in typical Harvard fashion, they are probably following Jesus Monroy's suggestion and hanging the engineers. Some of their "left front quarter panels" in fact have no mounting holes in them whatsoever: the PCI controllers with firmware versions that won't talk to Plato PCI motherboards (apparently in violation of the PCI 2.0 specification). Potentially they fail on other PCI boards as well, but sice they are know flakey, people who have a lot of hardware that could test this typically wouldn't buy one, especially if the expected outcome was that the board would be totally inoperable. Now you have several choices as a Buslogic purchaser: 1) Write your own driver; I'm sure the changes will be rolled back in, and there will be 40% coverage instead of the 20% you are complaining about. 2) Replace your firmware. On some versions of the board firmware, the board will remain inoperative because of failure of the board/firmware combination to meet the PCI 2.0 specification. The only alternative in these cases is to bring the firmware into compliance or replace the board with a compliant one, if it's a board problem. 3) Use a known good board/firmware combination. The "good" in this context refers both to the standards compliance of the card and to the driver availability. 4) Port VM86() from NetBSD and write a VM86() based disk driver. This will only cover the boards which are in spec, meaning 40% of the boards (a roughy guess) will probably continue to fail to operate. On the minus side, performance will be crap because DOS performance is crap. On the plus side, if it works with DOS, it'll work with BSD. This option is tantamount to following the suggestion "run DOS". 5) Return your card to the dealer for a card from a different manufacturer. Of these, option 5 has the best change of guaranteeing 100% success in your attempt to use the products. Currently, you have also purchased a Quantum Grand Prix drive, which are known to have the same type of QC problems as Buslogic. For BSD, that means your choice is limited to an AHA2940 card for PCI, unless you want to wait for the NCR 810/815/825 driver to be modified to work around the problems in the Grand Prix. Unfortunately, since it is a known flakey drive, the people maintaining the driver, being more familiar with the stability of SCSI drives, didn't choose to buy one. At this point, they would need a "loaner" (they are in Germany) to fix the problem (assuming they are interested). I would think the "path of least hassle" is to trade the Buslogic in for an Adaptec, which despite their developer support practices have had a driver written for them. Complaining to people who give away software about it not working with hardware you have and they don't (which puts you in a better position to track down the problem than they are) is unlikely to do nothing but get you arguments and suggestions that you fix the problem yourself. Regards, Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9505221743.AA14812>