From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 23:31:25 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F1D516A4CE for ; Tue, 13 Jul 2004 23:31:25 +0000 (GMT) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93A5E43D1F for ; Tue, 13 Jul 2004 23:31:24 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.12.9p2/8.12.9) with ESMTP id i6DNVM6E083424; Wed, 14 Jul 2004 03:31:22 +0400 (MSD) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.12.9p2/8.12.9/Submit) id i6DNVLHp083423; Wed, 14 Jul 2004 03:31:21 +0400 (MSD) (envelope-from yar) Date: Wed, 14 Jul 2004 03:31:21 +0400 From: Yar Tikhiy To: Jean-Sebastien Roy Message-ID: <20040713233120.GA79064@comp.chem.msu.su> References: <40EF172C.7020508@jeannot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40EF172C.7020508@jeannot.org> User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org Subject: Re: Silent errors when reading CDs X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2004 23:31:25 -0000 On Sat, Jul 10, 2004 at 12:07:40AM +0200, Jean-Sebastien Roy wrote: > > I'm currently using FreeBSD 4.10 on an HP D530 SFF. > The system is perfectly stable except for the following problem > I'm unable to understand : > > When I mount a cdrom (mount /cdrom), then calculate the MD5 hash > of a big file on a CD (md5 /cdrom/bigfile), the results are often random: > unmounting, mounting again and calculating again the MD5 often result in > a different value. What disturb me the most is that absolutely no errors > are reported in any log (no read errors for example). > > I thought the CDROM reader, a LITE-ON LTR-48327S PQS3, was the culprit, > so I replaced it with a PLEXTOR DVDR PX-712A and got the exact same > results (i.e. random MD5 values). I checked the RAM using memtest and > got no errors. The problem does not occur for files on the harddisk. Once I had an old noname PC (iP200 in an i430VX motherboard), and I installed a DVD+RW drive into it. Data read from a CD or DVD was damaged with high probability. With hw.ata.atapi_dma set to zero, the probability of data corruption was lower, but still noticable. That's while there were no corruption on burning in DMA or PIO mode. I got used to always checksumming data read or written; it was a real pain in the back. Finally, I dismantled the PC, but kept the DVD-RW drive for a new PC; thus I got rid of the problem once and for all. My conclusion was: If your hardware sucks, you may choose to work around the bugs, but it's usually easier to dump the POS and find a replacement. Of course, you may need to do some testing before you know which part sucks. > hw.ata.atapi_dma is set since both drives support it and it seems to be > required for proper CD/DVD burning. The CD drive is the master on its > own ATA bus. DMA mode on an ATAPI device might be the root of the evil. Alas, a lot of ATA controllers have bugs there. And you'll need DMA mode only for high-speed burning, when PIO mode cannot provide enough throughput--it's not required in general. E.g., I had DVD+Rs burned OK at 2.4x in PIO mode on the P200. Therefore you can at least see if disabling hw.ata.atapi_dma is a workaround for your problem. > While the problem occurs on multiple CDs (mostly RW), to my surprise, I > was not able to reproduce the problem by reading big files on DVDs. Are there CDs in your collection that produce no errors? > Could someone provide me a hint on what to check next or how to fix this > problem ? Can errors on CDs generate such a behavior ? Even a badly scratched CD won't produce damaged data unless read in a brain-dead drive. If your drives work OK with a different ATA controller, then it's probably your present ATA controller to blame. -- Yar