Re: Looking for porting account on AIX and others

2009-10-21 Thread Rob Bogus

Joerg Schilling wrote:

Hi,

the next final release for cdrtools is close and I am of course 
interested in giving the best possible. I unfortunately did not have

access to some pf the supported platforms for a long time and it
seems that AIX may be the most important platform from this list.

Is there somebody who is able to give me ssh login access to an AIX
machine with a compiler ready?

BTW: this is the current porting situation:

SunOS   (SunOS-3.x & SunOS-4.x) Test machine ready
Solaris (SunOS-5.x) Test machine ready
AIX ---
Apollo Domain   ---
AmigaOS ---
ATARI MiNT  ---
BeOS---
BSD-OS  ---
FreeBSD Test machine ready
NetBSD  Test machine ready
OpenBSD Test machine ready
DragonFlyBSDTest machine ready
DG-UX   ---
GNU-Hurd---
Cygwin on win32 Test machine ready
Cygwin on win64 Test machine ready
Max OS XTest machine ready
Haiku   Test machine ready
HP-UX   Test machine ready (10.20 % 
11.11)
IRIX---
Linux   Test machine ready
  
Which Linux? It runs on many CPUs, and at minimum x86_32, x86_64, SPARC 
and PPC are probably worth testing due to reasonable user base.

Reasonable defined "more than Hurd" in this case.


NextSTep---
OSF-1 (Digital UNIX)---
OS/2---
SCO OpenServer  Test machine ready
SCO UnixWareTest machine ready
Sony NEWS-OS---
SyllableTest machine ready
QNX ---
VMS ---
ZetaTest machine ready

I would love to get porting access to systems that are marked with "---"

So there are other platforms that are also of interest.

Thank you in advance!

Jörg

  



--
E. Robert Bogusta
 It seemed like a good idea at the time



--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org



Re: My Pioneer DVR-218L i think is behaving like the "LG GH20NS10 might hang at the end of DVD-R[W] DAO recording..."

2009-10-21 Thread Bill Davidsen

Lucas Levrel wrote:

Le 19 octobre 2009, Joerg Schilling a écrit :

  

Due to the well known bugs in "cdrkit" aka. "wodim", k3b prefers the original
software before the broken fork. 



But beware that some distributions (e.g. openSUSE 10.3) have a symlink 
/usr/bin/cdrecord -> wodim. So depending on PATH & installation details of 
genuine cdrecord, the latter may be unnoticed.


  
Calling wodim "cdrecord" is not unlike ordering Coke® and getting Pepsi® 
instead. It isn't about quality it's about the intent to deceive the 
user. If people wanted wodim they would ask for it by name. It's as fake 
as those "Pitsberg Stealers" (that's the way they spell it) sweatshirts 
you see at roadside stands near football games.



If available, one should have a look to k3b logs I guess...

  



--
Bill Davidsen 
 Unintended results are the well-earned reward for incompetence.



--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org



Re: solaris cdrecord BH08LS20 drive BD-R problems

2009-10-21 Thread Andy Polyakov
> ... 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*
Solaris?

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


-- 
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org