>>> If you like to prove that there >>> are Sparc machines with Solaris that behave different from what all other >>> users >>> reported, please send the related information: >>> >>> - exactly describe the machine type, the OS release and the drive type. >> Information can be found in attachments. > > Looking through the information does unfortunately not show anything that > verifies the presence of DMA for the CD-ROM drive in question.
Looking through the *requested* information does not show anything that verifies the presence *or absence* of DMA for the CD-ROM drive in question. SPARC Solaris does not tell a squat about DMA settings in /vad/adm/messages, 'eeprom' or 'prtconf -p' outputs. On the other hand, looking through the information provided *beyond* requested one allows to draw conclusion that DMA is *in fact* enabled for optical drive in question. Once again, target1-dcd-options is 0xa2 and more important read performance reaches 19MBps[!]. Indeed, there is no way venerable Blade-100 can deliver that much over PIO at *portion* of CPU power(*). As for value of 0xa2. Earlier I said that it denotes UDMA-2. As it turns out this was inaccurate. Upper bits, ones constituting 0xa?, do denote UDMA, but lower bits, ones constituting 0x?2, don't denote UDMA *mode*. Lower bits are meaningful when UDMA is disengaged and seem to denote PIO mode. In other words, while not being specific about UDMA mode, the value still tells that UDMA is actually enabled. (*) Well, patching uata driver to avoid DMA in atapi_ routines have shown that same experiment, pread(2) with fixed offset in loop, delivers not more than 2.7MBps at 95% of CPU time! Even though above is about SPARC Solaris 8 I found no evidence that DMA default settings for ATA would be different on SPARC Solaris 10 and even OpenSolaris for SPARC. Unfortunately I have no opportunity to confirm this experimentally. The conclusion is based on once observed target?-dcd-options value on SPARC Solaris 10, comparison of binary code for uata driver in all three releases, and on comparison of source code for Solaris 8 and OpenSolaris. All this naturally doesn't mean that all versions of SPARC Solaris *unconditionally* use DMA with ATAPI, but it's enough to conclude that originating "Solaris sparc still does not support DMA on ATA interfaces" is not justifiable. In the course of discussion it was also implied that cdrecord's "Solaris DMA related READMEs" are up-to-date with accuracy of 12 months and apply to *all* Solaris releases. To summarize, the READMEs discuss binary patching of ata binary driver on Solaris 9 x86 as the only way to engage DMA for optical ATAPI units. I don't recall when Solaris 10 was released, but from my >4 years personal experience with Solaris 10 x86 on Sun W1100z (Opteron-based workstation), it's perfectly possible to control DMA setting for optical ATAPI unit with atapi-cd-dma-enabled boot parameter and no binary patching is required. This applies even to OpenSolaris for x86 (where it's even properly documented in ata(7d)). Then there is enough evidence that the READMEs in question are not applicable to [any recent] SPARC Solaris release. At the very least on SPARC Solaris ATA is implemented by uata driver, which does not even have ata_init_drive_pcidma subroutine. Not to mention above information about DMA *defaults* for SPARC Solaris ATA support. A. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
