Date: Sat, 26 Mar 2005 15:22:11 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Colin J. Raven" <colin@kenmore.kozy-kabin.nl>, "FreeBSD Questions" <freebsd-questions@freebsd.org> Subject: RE: Anthony's drive issues.Re: ssh password delay Message-ID: <LOBBIFDAGNMAMLGJJCKNMEOIFAAA.tedm@toybox.placo.com> In-Reply-To: <20050326130042.S2949@kenmore.kozy-kabin.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
owner-freebsd-questions@freebsd.org wrote: > > I shouldn't have risen to this, but it's already gone from the > realms of > the sublime to the utterly absurd. Colin, After going back and forth on this problem for weeks, Anthony finally posted the microcode version that his Adaptec controller is using. This microcode is NOT the generic Adaptec microcode that Adaptec normally supplies with that controller - instead, it is Adaptec-supplied, HP-modified code. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. This I find strange because there have been many times disk manufacturers have posted corrected firmware for their disk drives - if nobody ever made mistakes in implementations, no one would ever post microcode updates. But for some reason Anthony does not believe in this, or if he does he is convinced that HIS disks have perfect SCSI implementations. 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, and that the problems he's having are not as a result in his hardware not being compliant with every other Adaptec adapter card, but are the result of some gross in the Adaptec driver. This despite that most people running Adaptec controllers with aic7880 chipsets in them under FreeBSD do NOT have problems. 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. Anthony has to acknowledge that it is HIS SYSTEM with the modified microcode that is the problem, and REQUEST that a workaround be added to the ahc() driver through the send-pr mechanism, as has been explained to him. For sheer pigheadedness, or pride, or stupidity, he cannot bring himself to do this. Ted
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?LOBBIFDAGNMAMLGJJCKNMEOIFAAA.tedm>