Re: solaris cdrecord BH08LS20 drive BD-R problems
>>> 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.
Reply to: