From owner-freebsd-questions@FreeBSD.ORG Tue Mar 22 12:07:33 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 9155416A4CE for ; Tue, 22 Mar 2005 12:07:33 +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 0CB5943D55 for ; Tue, 22 Mar 2005 12:07:33 +0000 (GMT) (envelope-from tedm@toybox.placo.com) Received: from tedwin2k (nat-rtr.freebsd-corp-net-guide.com [65.75.197.130]) j2MC7hb32130 for ; Tue, 22 Mar 2005 04:07:43 -0800 (PST) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: Date: Tue, 22 Mar 2005 04:07:32 -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: <1589026462.20050322120848@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 12:07:33 -0000 owner-freebsd-questions@freebsd.org wrote: > Ted Mittelstaedt writes: > >> 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 dates from before the change. They both show 10.00 MB/s now in > both the BIOS and dmesg, but the problem remains. > OK, well then that increases the chances that it is a driver issue and reduces the chances that it is a hardware issue. Assuming your termination is correct, that would increase chances it is a driver issue even more. Going to each single disk is what you really need to do now in order to make a definite finger point to the driver. You know, there is something else that coincidentally might relate to this. I have been working on a Compaq Professional workstation from time to time to setup a test workstation over the last week. It has a problem where under heavy use it will corrupt files written and read from the disk. This system was always a Windows box before, using a 1GB Seagate disk drive. (don't ask why Compaq would supply a 1GB disk it is rediculous) Here are some relevant bits of the dmesg that might interest you: . . CPU: Pentium Pro (199.31-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x619 Stepping = 9 Features=0xf9ff . . ahc0: port 0x1000-0x10ff mem 0x40080000-0x40080fff irq 11 at device 18.0 on pci0 aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs . . da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da0: 8191MB (16777215 512 byte sectors: 255H 63S/T 1044C) . . Now I can say one thing with certainty with this machine - Compaq has definitely modded the Adaptec microcode used on the controller here. Why do I know this? I know it because I tried removing the 2940 card from this machine and plugging it into another non-Compaq machine, and the card would not boot the disk in that system. However, a non-Compaq-labeled 2940 card works fine in that system. I had assumed the problem with this system was bad ram. But, I think I am going to try pulling that Quantum disk out of there and using a different one. > >> This is EXACTLY how it is done in real life. > > Yes, I know how it's done in real life. > Then why did you say it was done differently in your earlier post? Ted