It's not possible to install FreeBSD 9.0-RELEASE from CDROM on a Blade 1500, because bsdinstall reports a corrupt base.txz. Investigating the issue further, revealed that the 9.0 kernel corrupts data read from a CDROM mounted via /dev/cd0, while the 8.2 kernel doesn't corrupt data when the CDROM is mounted via /dev/acd0. Fix: No fix known yet. Workaround: netboot 9.0, or source-upgrade from a previous release. Don't use CDROM (/dev/cd0) on 9.0 until this bug is fixed. How-To-Repeat: 8.2-RELEASE doesn't exhibit the bug: 1. Install 8.2-RELEASE on a sun4u system. 2. Mount the 9.0-RELEASE CDROM (using /dev/acd0) 3. cd /cdrom/usr/freebsd-dist; sha256 *.txz; 4. compare with MANIFEST -> same checksums. Upgrade to 9.0-RELEASE, e.g. from source: 4. mv /usr/src /usr/src.82 5. cd /; tar -xvpf /cdrom/usr/freebsd-dist/src.txz 6. source upgrade from 8.2 to 9.0 9.0-RELEASE exhibits the problem: 7. Reboot to 9.0-RELEASE 8. Mount the 9.0-RELEASE CDROM (using /dev/cd0) 9. cd /cdrom/usr/freebsd-dist; sha256 *.txz 10. compare checksums with MANIFEST -> different checksums! Reboot 9.0 userland to 8.2 (/boot/kernel.old/kernel) and repeat sha256 checksums -> no errors. Note, the sha256 program on 9.0 yields the same checksums on arbitrary files than on 8.2, as long as those files are not read from CDROM (e.g. fetched from the net). It is okay.
> Workaround: netboot 9.0, or source-upgrade from a previous > release. Don't use CDROM (/dev/cd0) on 9.0 until this bug > is fixed. 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? Marius
On 20.01.2012 19:51, Marius Strobl wrote: > 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. -- Alexander Motin
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. Marius
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? -- Alexander Motin
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
On Fri, Jan 20, 2012 at 08:50:05PM +0100, Marius Strobl wrote: > 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. ... for the ALi M5229 rev. 0xc4 that is. The CMD 646 is limited to WDMA2 in the firstplace, a user also reported data corruption with these though. Marius
On Sat, Jan 21, 2012 at 01:59:19AM +0100, Marius Strobl wrote: > On Fri, Jan 20, 2012 at 08:50:05PM +0100, Marius Strobl wrote: > > 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. > > ... for the ALi M5229 rev. 0xc4 that is. The CMD 646 is limited to > WDMA2 in the firstplace, a user also reported data corruption with > these though. > I can also confirm the problem with CMD 646 but it turns out there's no problem when using the PATA port of an add-on VT6421A with otherwise identical hardware. So the data corruption apparently isn't due to a 64-bit or endianness bug in the ATA_CAM code (besides looking fine in this regard). At least for ata_aceride(4) I've also double-checked the generic initialization and the mode setting but can't spot any issue there. Does ATA_CAM+cd(4) do anything fundamentally different than acd(4)? Marius
Author: marius Date: Fri Jan 27 21:52:59 2012 New Revision: 230627 URL: http://svn.freebsd.org/changeset/base/230627 Log: Using ATA_CAM along with ATAPI DMA causes data corruption with ALI_NEW and CMD controllers for reasons unknown so disable it. PR: 164226 Modified: head/sys/dev/ata/chipsets/ata-acerlabs.c head/sys/dev/ata/chipsets/ata-siliconimage.c Modified: head/sys/dev/ata/chipsets/ata-acerlabs.c ============================================================================== --- head/sys/dev/ata/chipsets/ata-acerlabs.c Fri Jan 27 21:49:02 2012 (r230626) +++ head/sys/dev/ata/chipsets/ata-acerlabs.c Fri Jan 27 21:52:59 2012 (r230627) @@ -213,6 +213,10 @@ ata_ali_ch_attach(device_t dev) if (ch->dma.max_iosize > 256 * 512) ch->dma.max_iosize = 256 * 512; } +#ifdef ATA_CAM + if (ctlr->chip->cfg2 & ALI_NEW) + ch->flags |= ATA_NO_ATAPI_DMA; +#endif return 0; } Modified: head/sys/dev/ata/chipsets/ata-siliconimage.c ============================================================================== --- head/sys/dev/ata/chipsets/ata-siliconimage.c Fri Jan 27 21:49:02 2012 (r230626) +++ head/sys/dev/ata/chipsets/ata-siliconimage.c Fri Jan 27 21:52:59 2012 (r230627) @@ -240,6 +240,10 @@ ata_cmd_ch_attach(device_t dev) if (ctlr->chip->cfg2 & SII_INTR) ch->hw.status = ata_cmd_status; +#ifdef ATA_CAM + ch->flags |= ATA_NO_ATAPI_DMA; +#endif + return 0; } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Author: marius Date: Wed Feb 1 21:08:33 2012 New Revision: 230880 URL: http://svn.freebsd.org/changeset/base/230880 Log: MFC: r230627 Using ATA_CAM along with ATAPI DMA causes data corruption with ALI_NEW and CMD controllers for reasons unknown so disable it. PR: 164226 Modified: stable/9/sys/dev/ata/chipsets/ata-acerlabs.c stable/9/sys/dev/ata/chipsets/ata-siliconimage.c Directory Properties: stable/9/sys/ (props changed) stable/9/sys/amd64/include/xen/ (props changed) stable/9/sys/boot/ (props changed) stable/9/sys/boot/i386/efi/ (props changed) stable/9/sys/boot/ia64/efi/ (props changed) stable/9/sys/boot/ia64/ski/ (props changed) stable/9/sys/boot/powerpc/boot1.chrp/ (props changed) stable/9/sys/boot/powerpc/ofw/ (props changed) stable/9/sys/cddl/contrib/opensolaris/ (props changed) stable/9/sys/conf/ (props changed) stable/9/sys/contrib/dev/acpica/ (props changed) stable/9/sys/contrib/octeon-sdk/ (props changed) stable/9/sys/contrib/pf/ (props changed) stable/9/sys/contrib/x86emu/ (props changed) Modified: stable/9/sys/dev/ata/chipsets/ata-acerlabs.c ============================================================================== --- stable/9/sys/dev/ata/chipsets/ata-acerlabs.c Wed Feb 1 20:19:33 2012 (r230879) +++ stable/9/sys/dev/ata/chipsets/ata-acerlabs.c Wed Feb 1 21:08:33 2012 (r230880) @@ -213,6 +213,10 @@ ata_ali_ch_attach(device_t dev) if (ch->dma.max_iosize > 256 * 512) ch->dma.max_iosize = 256 * 512; } +#ifdef ATA_CAM + if (ctlr->chip->cfg2 & ALI_NEW) + ch->flags |= ATA_NO_ATAPI_DMA; +#endif return 0; } Modified: stable/9/sys/dev/ata/chipsets/ata-siliconimage.c ============================================================================== --- stable/9/sys/dev/ata/chipsets/ata-siliconimage.c Wed Feb 1 20:19:33 2012 (r230879) +++ stable/9/sys/dev/ata/chipsets/ata-siliconimage.c Wed Feb 1 21:08:33 2012 (r230880) @@ -240,6 +240,10 @@ ata_cmd_ch_attach(device_t dev) if (ctlr->chip->cfg2 & SII_INTR) ch->hw.status = ata_cmd_status; +#ifdef ATA_CAM + ch->flags |= ATA_NO_ATAPI_DMA; +#endif + return 0; } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Author: marius Date: Wed Feb 1 21:08:35 2012 New Revision: 230881 URL: http://svn.freebsd.org/changeset/base/230881 Log: MFC: r230627 Using ATA_CAM along with ATAPI DMA causes data corruption with ALI_NEW and CMD controllers for reasons unknown so disable it. PR: 164226 Modified: stable/8/sys/dev/ata/chipsets/ata-acerlabs.c stable/8/sys/dev/ata/chipsets/ata-siliconimage.c Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) stable/8/sys/dev/e1000/ (props changed) Modified: stable/8/sys/dev/ata/chipsets/ata-acerlabs.c ============================================================================== --- stable/8/sys/dev/ata/chipsets/ata-acerlabs.c Wed Feb 1 21:08:33 2012 (r230880) +++ stable/8/sys/dev/ata/chipsets/ata-acerlabs.c Wed Feb 1 21:08:35 2012 (r230881) @@ -213,6 +213,10 @@ ata_ali_ch_attach(device_t dev) if (ch->dma.max_iosize > 256 * 512) ch->dma.max_iosize = 256 * 512; } +#ifdef ATA_CAM + if (ctlr->chip->cfg2 & ALI_NEW) + ch->flags |= ATA_NO_ATAPI_DMA; +#endif return 0; } Modified: stable/8/sys/dev/ata/chipsets/ata-siliconimage.c ============================================================================== --- stable/8/sys/dev/ata/chipsets/ata-siliconimage.c Wed Feb 1 21:08:33 2012 (r230880) +++ stable/8/sys/dev/ata/chipsets/ata-siliconimage.c Wed Feb 1 21:08:35 2012 (r230881) @@ -240,6 +240,10 @@ ata_cmd_ch_attach(device_t dev) if (ctlr->chip->cfg2 & SII_INTR) ch->hw.status = ata_cmd_status; +#ifdef ATA_CAM + ch->flags |= ATA_NO_ATAPI_DMA; +#endif + return 0; } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
I was able to create a release build from the 9.0-CURRENT sources earlier today (20120208), and successfully booted the release.iso on a spare netra-t105. While, I didn't install from the disk, I was able to select "Shell", and then use "sha256" on all .txz files in /usr/freebsd-dist, and all the checksums matched those in the MANIFEST file. I was unable to get the sha256 checksums to match like this on the 9.0-RELEASE kernel. (Or 9.0-RC3 for that matter, where I first noticed it failing.) I think that turning off the DMA access for the cdrom works around the corruption issue. -Kurt
I built a 9.0-STABLE distribution on Friday (Fri Jul 6 21:43:11 EDT 2012), including building a .iso (make release). I then burned the resulting .iso onto a disks, and successfully booted from, and installed from that iso image on a netra-t1. I had no problems with DMA issues on the local DVD drive. (I replaced the CD-ROM in the machine with a slim-line DVD years ago.) So, I have successfully tested the patches referred to in this PR, I believe it can closed. -Kurt
What's in the tree now is just a work around but the underlying problem still exists and is yet to be solved so it's appropriate to leave this PR in an open state. I'm not sure what's the best assignee though; as it turned out later this problem isn't sparc64-specific at all. As it's ATA_CAM related mav@ would be best, but he unfortunately doesn't seem to be interested that much in fixing it ... Marius
State Changed From-To: open->suspended Submitter notes that the problem has been worked around in FreeBSD post-9.0R; but the underlying problem still needs to be solved.
Most likely obsoleted by subsequent events.