[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: solaris cdrecord BH08LS20 drive BD-R problems

> ... there is DMA.
>> 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.
> The variable atapi-cd-dma-enabled was introduced for Solaris 10.
> Before _all_ CDs always had no DMA.

Given placement of the remark any sane person would assume that it
refers SPARC Solaris 10, wouldn't [s]he? Well, the boot variable was
introduced in Solaris 10 x86[!] and the variable is Solaris x86
specific! It has no meaning on SPARC Solaris [not to mention that it's
impossible to set any custom boot variable with eeprom(sparc)]!

>> 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.
> They are as correct as they can be with the feedback from users...

Quoting Jörg: "Unless this changed during the past 12 month, my
information is of course correct and up to date." This remark was also
made as reply to my "SPARC Solaris [8] *is* capable of DMA." Any sane
person would interpret it as "Jörg has looked over the information about
a year ago and verified that there is nothing to add and patching ata
binary driver is still the only way to engage DMA for optical ATAPI unit
on Solaris versions >=9, both x86 and SPARC." The latter is far from
true. 1. Solaris >=10 x86 has atapi-cd-dma-enabled (as already mentioned
multiple times) 2. It does *not* apply to SPARC Solaris (see below).

READMEs are as correct as they are in specific context of Solaris 9 x86!
 One shouldn't imply [or rather it wrong to imply] anything more than that.

>> 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...

That's why I wrote "experience with Solaris 10 *x86*."

>> 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.
> As you could see, my patch is for sparc

What "my patch is for sparc" are you talking about? One found in
README.solaris-x86-ATAPI-DMA? If you meant "my patch is for x86", then
how does it support your argument about DMA default being off on *SPARC*

> and you should know that with Solaris 11
> DMA is finally used by default.

And so should you, and consequently should not imply that READMEs are
perfectly up-to-date. And DMA is *finally* by default on in Solaris 11
x86[!]. On SPARC Solaris it was by default since *earlier*.

> 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.

I did *nothing*! On the contrary, as mentioned earlier I had to patch
uata binary to get rid of DMA! As already stated several times, *DMA is
on by default on SPARC Solaris >=8* (maybe since earlier, I simply have
no data on earlier releases). The setting appears to be negotiated upon
uata driver initialization. If DMA ended up off on somebody's system, I
would guess that driver failed to negotiate it. Maybe there is jumper on
the unit, maybe specific unit is not fully compliant with ATA
specification which can be reason for failure. I don't know. But it
doesn't mean that one can draw conclusion that DMA is off by default and
state "Solaris sparc *still* does not support DMA on ATA interfaces". A.

Reply to: