From owner-freebsd-current Mon Apr 15 5:54:43 2002 Delivered-To: freebsd-current@freebsd.org Received: from harrier.prod.itd.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by hub.freebsd.org (Postfix) with ESMTP id CE80037B405; Mon, 15 Apr 2002 05:54:37 -0700 (PDT) Received: from pool0028.cvx21-bradley.dialup.earthlink.net ([209.179.192.28] helo=mindspring.com) by harrier.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16x5zs-0004y4-00; Mon, 15 Apr 2002 05:54:17 -0700 Message-ID: <3CBACD5A.92900331@mindspring.com> Date: Mon, 15 Apr 2002 05:53:46 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sos@freebsd.dk Cc: Giorgos Keramidas , Alexander Leidinger , dwcjr@inethouston.net, current@FreeBSD.ORG, sos@FreeBSD.ORG Subject: Re: ATA errors on recent -current References: <200204151223.g3FCNI541636@freebsd.dk> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "S=F8ren Schmidt" wrote: > > For a more "scientific test", downloading the firmware tool and > > setting the DMA transfer rate down, and checking for problems, > > would be pretty overwhelming evidence. Personally, I don't have > > any of the buggers lying around to test with any more. > = > Why on earth would you do that ? (hint man atacontrol) > = > Besides I dont see this as any evidence at all, but thats another matte= r... If it fixes the problem, then the problem is most likely related to what firmware setting the tool changes. 8-). =46rom my reading of the FreeBSD man pages, it can't blow the flash byte that controls the DMA speed, like the IBM provided utility does. Obviously, turning off tagged commands works, according to at least one person who is reporting the problem. I wonder if limiting outstanding tagged commands to less than the number advertised by the drive would also work... can't be worse than the initialization reordering patch that failed (e.g the worst case is it still has the problems). A lot safer than banging bits in the firmware, I'm sure, though... Limiting the outstanding tagged commands to less than the advertised amount would actually be my first choice of a hack for a software workaround. Can you do that with "sysctl hw.ata.tags=3DXXX"? Or is that just a 1/0 thing? A scan doesn't indicate documentation, but I'm probably just not looking very hard... -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message