From owner-freebsd-hackers Wed Feb 20 13:19:25 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from avocet.prod.itd.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by hub.freebsd.org (Postfix) with ESMTP id 7A7B137B426 for ; Wed, 20 Feb 2002 13:18:50 -0800 (PST) Received: from pool0067.cvx40-bradley.dialup.earthlink.net ([216.244.42.67] helo=mindspring.com) by avocet.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16de8I-0004Td-00; Wed, 20 Feb 2002 13:18:35 -0800 Message-ID: <3C74129F.D8A12732@mindspring.com> Date: Wed, 20 Feb 2002 13:18:23 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Gallatin Cc: sos@freebsd.dk, freebsd-hackers@FreeBSD.ORG Subject: Re: Serverworks ATA controller & data corruption 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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). 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. 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. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message