Date: Sun, 27 Mar 2005 11:22:06 +0200 From: Anthony Atkielski <atkielski.anthony@wanadoo.fr> To: freebsd-questions@freebsd.org Subject: Re: Anthony's drive issues.Re: ssh password delay Message-ID: <154613622.20050327112206@wanadoo.fr> In-Reply-To: <LOBBIFDAGNMAMLGJJCKNMEOIFAAA.tedm@toybox.placo.com> References: <20050326130042.S2949@kenmore.kozy-kabin.nl> <LOBBIFDAGNMAMLGJJCKNMEOIFAAA.tedm@toybox.placo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ted Mittelstaedt writes: > In a case like this it is very likely a BSD driver issue - why, > because the FreeBSD driver author could not test with every > custom-modified microcode when he wrote the driver. There is no list > out there of every computer company who has had a source license to > the Adaptec microcode and made modifications to it. And naturally you > would assume that anyone making mods to the SCSI microcode would have > the brains not to break it. In this case that didn't happen. Most > likely HP modified the Adaptec microcode because of bugs in the disks > that they were supplying with the original Vectras. I wouldn't automatically assume that there were _bugs_ in the disks. Companies that modify things in this way usually do so because they are under the mistaken impression that they can somehow build a "better" machine by throwing away all the standard stuff and home-brewing their own branded versions of everything (the phenomenon isn't limited to just computers, either). This is one argument _against_ buying major brands; at least when you buy a no-name brand off the shelf or build something yourself, everything on the machine is likely to be conformant to industry standards. HP probably thought they were doing the world a favor by modifying the firmware--they probably thought they were "adding value," instead of diminishing compatibility and maintainability. I don't agree with them, but that's neither here nor there now. As far as I know, the disk drives themselves are off-the-shelf drives. One is a Western Digital Barracuda, and the other is a Quantum Atlas, if I remember correctly. Both were branded HP on the box, but the drives themselves carry the original manufacturers' labels. > The reason he wasn't seeing problems with NT on the system was that as > we all know Microsoft obtains samples of every name-brand system that > is ever manufactured specifically for compatibility testing, and they > probably already ran into this problem and put a workaround in their > driver. This isn't nearly as universal as you imply. Microsoft is regularly bitten by custom-modified software and hardware on computers used by its customers. That includes computers built by major brands such as HP/COMPAQ, Dell, and so on. Sometimes a vendor will have a specific configuration formally certified by Microsoft for use with Windows; but if it doesn't, or if it makes any change at all in the configuration after certification, the result may not work. The most desperate customers may actually loan some of their actual machines to Microsoft PSS in order to help the latter find problems and workarounds. The hardware vendors are not always cooperative, and sometimes they seem to be clueless about their own modifications. In this case, given that this was a high-end machine from a major brand that came with Windows NT preinstalled, it may have been formally certified by Microsoft (although I removed the pre-installed copy of French Windows NT Workstation and replaced it with U.S. English Windows NT Server, which still ran okay). But things don't always turn out so happily. > I have noticed a similar problem on the same Adaptec controller in a > Compaq system which is running Adaptec-supplied, Compaq-modified > microcode and a Quantum disk drive. I have MANY systems running the > same Adaptec controller that are using genuine Adaptec adapters which > are using Adaptec microcode that is not modded by some computer > company, that run perfectly fine. The differences in microcode are probably minor. Hardware manufacturers may be willing to let computer companies cook up custom versions of microcode, but I daresay they are far less willing to come up with custom _hardware_ for computer companies, which would cost a fortune--no computer company is likely to bring in enough business to justify a significant hardware change. So naturally the microcode can't drift too much if it has to stay compatible with the same hardware. But it can easily drift enough to screw up the software. > It is beyond comprehension why companies like Compaq and HP see fit to > fuck around with the perfectly good Adaptec microcode. But the fact is > that in my and in his system, they have done so. They want to be different. They think they are so important and so special that everything has to be altered by their magic touch. They fantasize that customers will say "no, I don't want that standard firmware, I want REAL HP/COMPAQ firmware, it's so much nicer!" Of course, that doesn't happen in real life, and if anything, the custom stuff works against them. Customers moan and groan about the custom stuff all the time. About 99% of the vendor-specific stuff serves no discernable purpose, and just makes the systems harder to use and maintain. They will run okay in the EXACT configuration that came preinstalled from the factory; but if you so much as look at a jumper, things will start to fail. > His three choices are to first: try a different SCSI disk from a > different manufacturer, in the hopes that it might behave with the > modified microcode. Too expensive, and I don't even know if compatible SCSI disks still exist. > As I've explained to him I've had problems with Quantum SCSI disks > in the past and I don't use them - if he reverts to his single Seagate > disk he might get lucky and the problem go away - then he will know > to buy a bigger Seagate if he needs more space. Also too much trouble. > Second, he can go into BIOS and disable the on-motherboard SCSI > controllers and use an off-the-shelf controller, like a cheap > symbiosis or NCR one for example. See above. > Third, he can try to contact the FreeBSD developer who is assigned to > the ahc() driver, tell that person that he has an HP Vectra that uses > a aic7880 chipset that is running microcode that HP modified, and that > his system is having problems, and offer that person his system for > testing. He may need to ship his system to that developer or more > likely put an IDE disk in it that has a running BSD system on it, > attach a disk to the Adaptec controller, put it on the Internet and > set it up for remote access so the developer can examine it. Hmm ... interesting, but I'd have to open the firewall, which makes me nervous. > In my case, I'm going to try a different SCSI disk in hopes that the > interaction between the Compaq-modified SCSI adapter and the disk > drive is different and does not trigger whatever bug Compaq introduced > into the Adaptec microcode. And if that doesen't work I'll just remove > the SCSI adapter and throw it in the garbage and put in a genuine > Adaptec adapter. Anthony cannot do this because he doesen't have a > separate adapter, his SCSI chipset is on the motherboard. If he > updated BIOS there's a slight possibility that the updated BIOS might > carry a later rev. of microcode - but I am pretty sure with that > Adaptec chipset that the microcode was in a ROM not in an EEPROM so it > can't be updated. I never liked on-board hardware. I would have preferred that HP build the machine with a separate included SCSI controller card. > But Anthony's biggest obstacles to this are that a) he doesen't > believe in bugs that appear as a result of interactions between > microcode in disk drives and microcode in SCSI adapters, he seems to > feel that everyone in the business exactly perfectly follows the SCSI > standard when they manufacture disks and controllers. No, Anthony doesn't believe that hardware failures appear when one switches from one OS to another. Either the hardware works, or it doesn't. Problems that move with the OS are software bugs, as you've just explained above. > ... and b) Anthony is convinced that his Vectra has an Adaptec chipset and > microcode that runs that chipset that is pefectly good and identically > compliant to every other Adaptec chipset ... I don't recall ever saying anything about the microcode, only the hardware. > With that sort of attitude if he were to approach the author of the ahc() > driver he would be told to stick his head up his ass. Whereas Microsoft just modified the OS to accommodate the special microcode. That's why Microsoft is number one. -- Anthony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?154613622.20050327112206>