Date: Fri, 20 Jan 2012 20:00:30 GMT From: Marius Strobl <marius@alchemy.franken.de> To: freebsd-sparc64@FreeBSD.org Subject: Re: sparc64/164226: Data corruption on 9.0-RELEASE when reading from CDROM Message-ID: <201201202000.q0KK0Ubd047155@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR sparc64/164226; it has been noted by GNATS. From: Marius Strobl <marius@alchemy.franken.de> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-gnats-submit@FreeBSD.org, "C. P. Ghost" <cpghost@cordula.ws> Subject: Re: sparc64/164226: Data corruption on 9.0-RELEASE when reading from CDROM Date: Fri, 20 Jan 2012 20:50:05 +0100 On Fri, Jan 20, 2012 at 09:40:35PM +0200, Alexander Motin wrote: > On 01/20/12 21:32, Marius Strobl wrote: > >On Fri, Jan 20, 2012 at 08:13:38PM +0200, Alexander Motin wrote: > >>On 20.01.2012 19:51, Marius Strobl wrote: > >>>Alexander, could you please look into this? > >>>Apparently, using cd(4) with ATA_CAM on sparc64 causes seemingly > >>>random data corruption while using the same hardware with acd(4) > >>>doesn't. Also cd(4) works just fine with SPI CD-ROMs. This affects > >>>CD-ROMs connected to both AcerLabs M5229 and CMD 646. > >>>Btw., apparently hw.ata.ata_dma and w.ata.atapi_dma no longer > >>>work when using ATA_CAM as ata_getparam() isn't called in the > >>>first place. On a quick glance hw.ata.ata_dma_check_80pin and > >>>hw.ata.wc probably also are no longer available with ATA_CAM. > >>>Is there an alternative to these tunables to achieve the same > >>>when using ATA_CAM? > >> > >>hw.ata.ata_dma and hw.ata.atapi_dma are indeed no longer exist. But > >>hint.ata.X.mode and hint.ata.X.devX.mode are working. In run tame it can > >>be done via `camcontrol negotiate cd0 -U -M mode; camcontrol rescan X`, > >>where X is a CAM bus number. > >> > >>hw.ata.ata_dma_check_80pin still exist, but CAM ATA transport is no > >>longer look on whet device thinks about cable type. It is tricky in SATA > >>world. Cable type is checked only from controller driver side now. Looks > >>like none of mentioned controller drivers are doing it. > >> > >>hw.ata.wc was replaced by kern.cam.ada.write_cache and > >>kern.cam.ada.X.write_cache. > >> > >>I would start experiments from limiting transfer speed manually. > > > >Hrm, limitting the mode to PIO avoids the data corruption with > >ATA_CAM. > > What's about limiting speed to UDMA33? Is it DMA problem or result of > dropped device side cable detection that could limit to UDMA33 before? > Apparently it's some sort of DMA problem. UDMA2 is also the maximum negotiated with acd(4). Limitting to UDMA1, UDMA0 or even WDMA0 makes no differnce to the problem. Marius
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201201202000.q0KK0Ubd047155>