Date: Wed, 20 Feb 2002 16:33:07 -0500 (EST) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Terry Lambert <tlambert2@mindspring.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Serverworks ATA controller & data corruption Message-ID: <15476.5651.117914.794606@grasshopper.cs.duke.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15476.5651.117914.794606>