From owner-freebsd-hackers Wed Feb 20 13:33:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id C4A5937B404 for ; Wed, 20 Feb 2002 13:33:37 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id QAA29619; Wed, 20 Feb 2002 16:33:37 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g1KLX7566238; Wed, 20 Feb 2002 16:33:07 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15476.5651.117914.794606@grasshopper.cs.duke.edu> Date: Wed, 20 Feb 2002 16:33:07 -0500 (EST) To: Terry Lambert Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Serverworks ATA controller & data corruption In-Reply-To: <3C74129F.D8A12732@mindspring.com> References: <15475.50753.252494.269972@grasshopper.cs.duke.edu> <200202201953.g1KJrKq77437@freebsd.dk> <15476.1618.379112.915616@grasshopper.cs.duke.edu> <3C740DE2.B028B5A5@mindspring.com> <15476.4032.768679.823788@grasshopper.cs.duke.edu> <3C74129F.D8A12732@mindspring.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Terry Lambert writes: > Andrew Gallatin wrote: > > Terry Lambert writes: > > > > So.. Is PIO safe? Is there any sort of CRC being done on PIO data? > > > > > > He just said: if your chipset is programmed correctly > > > by the BIOS, then there will not be a problem, but > > > apparently, there is a very narrow band of "correctly" > > > (perhaps even only a single state), and the vendor > > > apparently does not default the chip into that state. > > > > I was asking a more general question about ATA -- I know that UDMA has > > has some sort of CRC protection because (on other machines) I've seen > > the occasional error about a bad CRC, retrying. But what I don't know > > is if PIO offers the same protection. > > PIO is safe. The problem with ATA DMA needing the CRC is > to recover from the case where the DMA is aborted in the > middle, which is not signalled (this was the problem with > the CMD640B ATA chipset interface on Intel). Or marginal cables, I'd assume. > In fact, you might want to try enabling the CMD640B workaround > on your system, even though it is not probing a CMD640B > present, and see if that fixes it (the chipset in question > might be using the same macrocell in its implementation, or > it might just be similarly buggy). If that worked, then you > could leave the DMA enabled. Ick. No thanks. > PIO makes the host CPU do the work... basically, it's like a > WinModem, only for ATA interfaces, and it's documented. 8-(. > > Actually, now that I think about it, using the main CPU and > doinf PIO might be better anyway, given the speed difference > between the main CPU and the DMA engine on the ATA chip; the > overall performance may even be up to 2x better using the > host CPU to do the work, particularly if you special case > the transfer alignment, the way bcopy does. Not without write combining, at least, and PIO reads suck for x86s almost universally. To add insult to injury, most revs of this chip have a well known PIO corruption bug when write combining is enabled. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message