From owner-freebsd-questions@FreeBSD.ORG Tue Mar 22 10:46:21 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98A9316A4CE for ; Tue, 22 Mar 2005 10:46:21 +0000 (GMT) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [65.75.192.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0E8343D31 for ; Tue, 22 Mar 2005 10:46:20 +0000 (GMT) (envelope-from tedm@toybox.placo.com) Received: from tedwin2k (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) j2MAkVb31805 for ; Tue, 22 Mar 2005 02:46:31 -0800 (PST) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: Date: Tue, 22 Mar 2005 02:46:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <1907678552.20050322101315@wanadoo.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 Importance: Normal Subject: RE: Anthony's drive issues.Re: ssh password delay X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2005 10:46:21 -0000 owner-freebsd-questions@freebsd.org wrote: > Ted Mittelstaedt writes: > >> I have told him to go into his Vectra BIOS and limit the sync >> negotiation on both disk drives to the same speed - 10Mbt. He >> refuses to try doing this. > > You're incorrect. I have _already_ done it, at your suggestion; it > had no effect, as I expected. > The dmesg you sent indicated that the 2 disks were negotiating at different sync rates. If you did limit them to 10mbt sync negotiation as you stated, then why does the dmesg show them at different rates? It seems to me that either you didn't limit them, or you did limit them and the SCSI controller or the Quantum disk overrode the limit anyway. In which case it would not have had any effect. I recall warning that this probably wouldn't work but it was the only simple and quick test that didn't involve cracking the case that I could think of. You should have seen that the limit was being ignored as soon as you rebooted. I also don't recall you posting the result of this test either in which case I would have reminded you it was a long shot anyway. >> I've also told him to remove the Quantum and try running a FreeBSD >> system off the Seagate, to see if it errors with just the single >> Seagate drive on it. He refuses to do that either. > > I'm not going to take the machine apart just to eliminate every other > possible cause in the universe before blaming it on FreeBSD. > Of course, because you know perfectly well that doing this would really prove it's either the hardware or FreeBSD, and you don't want to take the risk of it being hardware, and looking like a fool. > Only one thing has changed in this machine: I replaced Windows NT with > FreeBSD. Windows NT had no problem with the SCSI drives; FreeBSD has > a problem with them. Therefore FreeBSD is defective. > Let's assume for the sake of argument that a SCSI guru comes over to your house with a $100K hardware SCSI analyzer, determines it's a bug in the Adaptec microcode, then writes in a workaround in the driver. You would take it as proof that the FreeBSD driver was buggy - because it didn't contain the workaround for your buggy hardware. In short, in your universe, the only possible thing your going to believe is that it's a bug in the FreeBSD driver. Even if the bug isn't in the driver but in the hardware and the driver implements a kludge for it. > All I know, is that nobody who has replied to my questions is > competent or energetic enough to actually find the bug in FreeBSD. > You can argue all you want about that, but it's precisely this sort > of attitude that prevents operating systems like FreeBSD from being > adopted on a large scale in many organizations. If they delete NT to > try FreeBSD, and FreeBSD generates a raft of errors that NT never > did, and all anyone involved with the product can say is "it's your > hardware!" do you think that they're going to keep using FreeBSD? > The OS is obviously defective, since it is the only thing that > changed. There is no reason to look anywhere else UNTIL and UNLESS > the OS is ruled. Looking at everything else _first_ just to avoid > taking responsibility > for a bug in > the OS is not the way it's done. > Anthony, I have had EXACTLY the same kind of problem with NT4 back in 1998 when I was working for a company named Portland Software. (since defunct) In my instance it was a Pentium 200 clone motherboard with, as I recall, an Adaptec SCSI card in it (a relabled Future Domain controller that Adaptec bought and sold for a few years then cancelled) In fact, it wasn't just 1 it was 2 of these boards in identical servers. In one server it worked fine. In the other, with the exact same hardware, controller, disks, etc. NT bluescreened when I put more than 2 SCSI disks on the bus. NT ran fine with 2 or 1 disks. All 6 disks were the same model and mfgr. (quantum's actually) At the time Portland Software had not just a regular service contract/site license with Microsoft, they had a developers contract which allowed you to place calls to the extra-special tech support hotlines. I placed my call. Over the next month I sent a total of 5 dumps to Microsoft, trying to get them to tell me if it was a hardware bug or software driver bug (unlike you, I was willing to accept that it might of been a hardware bug despite the fact that the motherboards, disks, and controllers were all brand new) and if possible to write a workaround or fix into the driver. I got exactly nowhere. Oh sure, the tech support person claimed that the problem had been escalated to the developer. But they would just go away for a few days then e-mail requesting another dump. Then repeat the process. Meantime a server was tied up that I needed. (you would not believe what the company was using previously as a server) Eventually I just lived with 2 disks in the server. (Another fix would have been to buy a different model of controller, no doubt) This is EXACTLY how it is done in real life. When you run into these bugs that you can correct by changing around hardware, you mark it down as a hardware bug, change around the hardware, and be done with it. Unless that is you have infinite time to play back-and-forth games with the software people and keep a server quarentined while your doing it. That is also when I discovered how Microsoft gets away with telling the world that they will fix any problem that you call into their $250-and-incident tech support people. If you present them with a problem they cannot figure out, they will just ask for dump after dump, over and over, until you get tired of it and go away. Then they mark it down to the customer not wanting to pursue the ticket and pat themselves on the back and claim this must mean it was never their fault to begin with. Ted