Andy Polyakov <[email protected]> wrote: > 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.
This is indeed a real hint that there is DMA. > (*) 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! I would not expect more than 4 MB/s for PIO > 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. The variable atapi-cd-dma-enabled was introduced for Solaris 10. Before _all_ CDs always had no DMA. This is a result of a bad bugtracking entry made by a Sun employee who incorrectly claimed that there are problems when DMA is enabled. As with Solaris 8 and 9 DMA was never used for CDs, I published the related patch that worked fine for Solaris 8 and 9 until recentliy with a Sun provided patch. > 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 They are as correct as they can be with the feedback from users... I do have negative feedback from two sysadmins who both have been unable to use a DVD writer on a sparc based system because of the lack of DMA and the fact that the writer did not like to enable burn-free if DMA is not active. Both could however confirm that using slow DVD-RW media at 2x write speed works. > 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 Opteron is not sparc... > 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. As you could see, my patch is for sparc and you should know that with Solaris 11 DMA is finally used by default. If you have been able to do something that other people could not do before (using a DVD drive with DMA on a sparc system), it would be nice if you could tell us how you did manage this. Well, the last sparc related feedback I received is more than a years old, so it is possible that a recent Solaris 10 patch fixed the problem. I did use sparc based systems at my primary desktop between 1988 and December 2007. I did always run the latest OS version and I was never able to see DMA for a PATA based DVD writer. Jörg -- EMail:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (uni) [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
