Re: Again... DMA speed too slow

Re: Again... DMA speed too slow

[Joerg Schilling]

>Which controller are you on?  I bet the recording itself will work fine
>on 48x.  It's probably that READ/WRITE BUFFERs are executed using PIO
>for compatibility reasons. 

If this happens inside Linux, Linux should be changed...

but note that wodim is based on 3 year old cdrecord code and cdrecord
is constantly evolving. A lot of problems in cdrecord have been fixed during 
the last years while wodim still uses the old code. If you like to judge you 
first should upgrade to a recent original cdrtools from:

ftp://ftp.berlios.de/pub/cdrecord/alpha/

2.01.01a38 is the latest. Install cdrecord suid root and try again.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Again... DMA speed too slow

[Alan Cox]

On Mon, 14 Apr 2008 18:54:22 +0200
Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) wrote:

> >Which controller are you on?  I bet the recording itself will work fine
> >on 48x.  It's probably that READ/WRITE BUFFERs are executed using PIO
> >for compatibility reasons. 
> 
> If this happens inside Linux, Linux should be changed...

The cases Linux falls back to PIO are the cases where the hardware isn't
up to it, or reliably handling some DMA commands. Lots of that about in
the PC world.

> 2.01.01a38 is the latest. Install cdrecord suid root

Remarkably brave ;)

Re: Again... DMA speed too slow

[Joerg Schilling]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> On Mon, 14 Apr 2008 18:54:22 +0200
> Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling) wrote:
>
> > >Which controller are you on?  I bet the recording itself will work fine
> > >on 48x.  It's probably that READ/WRITE BUFFERs are executed using PIO
> > >for compatibility reasons. 
> > 
> > If this happens inside Linux, Linux should be changed...
>
> The cases Linux falls back to PIO are the cases where the hardware isn't
> up to it, or reliably handling some DMA commands. Lots of that about in
> the PC world.

OK, I know that a few drives give wrong DMA speed test results on Solaris,
so the behavior for these drives seems to be unrelated to the OS.

Cdrecord is under constant development and for this reason, there are 
workareounds for these drives.

> > 2.01.01a38 is the latest. Install cdrecord suid root
>
> Remarkably brave ;)

I am not sure why you mention the term "brave", is it because all known Linux 
distributions still require suid root? In this case, I encourage you to inform 
yourself about the code quality of cdrecord. There was no known security problem 
during the past 4 years. Try to compare with other software ,-)



If you have problems with drives that implement no DMA with read buffer, just 
call:

CDR_FORCESPEED=any cdrecord ......

Another way to deal with the problem is to create a file /etc/default/cdrecord
and to configure to use burnfree by default for the related drive.

e.g. by using a line:

optiarc=          1,0,0	-1	-1	burnfree

and call "cdrecord dev=optiarc ..."

If there is interest in having a way to force any speed without swiching on 
burnfree, I may add an option that may be used in /etc/default/cdrecord with the
same effect as CDR_FORCESPEED=any



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Again... DMA speed too slow

[Alan Cox]

> OK, I know that a few drives give wrong DMA speed test results on Solaris,
> so the behavior for these drives seems to be unrelated to the OS.

Controllers don't always get DMA ATAPI right things like that - not
trivial little speed test details.

> I am not sure why you mention the term "brave", is it because all known Linux 
> distributions still require suid root? In this case, I encourage you to inform

Last time I checked almost all cd burning was being done non root.
 
Alan

Re: Again... DMA speed too slow

[Alan]

>> I am not sure why you mention the term "brave", is it because all known
>> Linux
>> distributions still require suid root? In this case, I encourage you to
>> inform
>
> Last time I checked almost all cd burning was being done non root.

Nero for Linux seems to be an exception.  It wants to write to raw devices
that non-root users do not have permissions for.

Re: Again... DMA speed too slow

[Joerg Schilling]

"Alan" <alan@clueserver.org> wrote:

>
> >> I am not sure why you mention the term "brave", is it because all known
> >> Linux
> >> distributions still require suid root? In this case, I encourage you to
> >> inform
> >
> > Last time I checked almost all cd burning was being done non root.
>
> Nero for Linux seems to be an exception.  It wants to write to raw devices
> that non-root users do not have permissions for.

Not correct: Nero is not the exception.

All software that implements more than rudimentary functions needs root 
privileges on Linux (*). Some software may not check this in advance and may
later fail with obscure error messages.

*) with future Linux distributions this may change but there is currently no 
known Linux distribution that supports the needed feature.





Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Again... DMA speed too slow

[Joerg Schilling]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > OK, I know that a few drives give wrong DMA speed test results on Solaris,
> > so the behavior for these drives seems to be unrelated to the OS.
>
> Controllers don't always get DMA ATAPI right things like that - not
> trivial little speed test details.

Using the term "controller" is not specific enough to understand what you might
like to tell.


> > I am not sure why you mention the term "brave", is it because all known Linux 
> > distributions still require suid root? In this case, I encourage you to inform
>
> Last time I checked almost all cd burning was being done non root.

Looks like you are incorrectly informed in this area or you checked only software 
that does not work correclty in all cases ....

For your information:

Linux traditionally needed suid root for sending SCSI commands until someone 
introduced a bug in late 2.4 kernels. After this bug has been discovered, the 
Linux Kernel interface has been changed in an incomatible way. At the same time,
the Linux kernel started to filter SCSI commands. Some commands that are needed 
for CD/DVD writing still need root privileges, others don't.

Some people did take my working software and removed security checks.
The fact that it is possible to still write CDs under some conditions
does not prove anything. It justs verifies that the people who removed
those checks are not smart enough to find the assignements of the SCSI command
codes in cdrecord ;-)

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de                (uni)  
       schilling@fokus.fraunhofer.de     (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: Again... DMA speed too slow

[Robert Hancock]

J.A. Magallón wrote:
> Hi all...
> 
> I have tried to burn some data from the commandline with wodim (since time
> ago I just used beasero...), and I have noticed this (media is CD, not DVD):
> 
> Vendor_info    : 'HL-DT-ST'
> Identification : 'DVDRAM GSA-H10N '
> Revision       : 'JL12'
> Device seems to be: Generic mmc2 DVD-R/DVD-RW.
> Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
> Driver flags   : MMC-3 SWABAUDIO BURNFREE
> Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
> Speed set to 8467 KB/s
> wodim: DMA speed too slow (OK for 5x). Cannot write at speed 48x.
> Starting to write CD/DVD at speed  48.0 in real TAO mode for single session.
> 
> I just can burn CDs at 5x ??
> But then the program tries to write at 48x.
> It the DMA message really true ?

No, UDMA33 should be more than fast enough. My guess is that wodim is 
determining the DMA speed using some unreliable mechanism.

Again... DMA speed too slow

[J.A. Magallón]

Hi all...

I have tried to burn some data from the commandline with wodim (since time
ago I just used beasero...), and I have noticed this (media is CD, not DVD):

Vendor_info    : 'HL-DT-ST'
Identification : 'DVDRAM GSA-H10N '
Revision       : 'JL12'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Speed set to 8467 KB/s
wodim: DMA speed too slow (OK for 5x). Cannot write at speed 48x.
Starting to write CD/DVD at speed  48.0 in real TAO mode for single session.

I just can burn CDs at 5x ??
But then the program tries to write at 48x.
It the DMA message really true ?

Accodring to wodim -prcap:

  Maximum read  speed: 22161 kB/s (CD 125x, DVD 16x)
  Current read  speed: 22161 kB/s (CD 125x, DVD 16x)
  Maximum write speed: 11080 kB/s (CD  62x, DVD  8x)
  Current write speed: 11080 kB/s (CD  62x, DVD  8x)
  Rotational control selected: CLV/PCAV
  Buffer size in KB: 2048
  Copy management revision supported: 1
  Number of supported write speeds: 3
  Write speed # 0: 11080 kB/s CLV/PCAV (CD  62x, DVD  8x)
  Write speed # 1:  5540 kB/s CLV/PCAV (CD  31x, DVD  4x)
  Write speed # 2:  3324 kB/s CLV/PCAV (CD  18x, DVD  2x)

Why the tests in wodim say that DMA to the drive is slow ?

Kernel is 2.6.24.4.
The drive is controlled by libata+sata_promise:

sata_promise 0000:03:04.0: version 2.11
ACPI: PCI Interrupt 0000:03:04.0[A] -> GSI 23 (level, low) -> IRQ 17
scsi6 : sata_promise
scsi7 : sata_promise
scsi8 : sata_promise
ata5: SATA max UDMA/133 mmio m4096@0xf6029000 port 0xf6029200 irq 17
ata6: SATA max UDMA/133 mmio m4096@0xf6029000 port 0xf6029280 irq 17
ata7: PATA max UDMA/133 mmio m4096@0xf6029000 port 0xf6029300 irq 17
ata5: SATA link down (SStatus 0 SControl 300)
ata6: SATA link down (SStatus 0 SControl 0)
ata7.00: ATA-6: ST3120022A, 3.06, max UDMA/100
ata7.00: 234441648 sectors, multi 0: LBA48
ata7.01: ATAPI: HL-DT-ST DVDRAM GSA-H10N, JL12, max UDMA/33
ata7.00: configured for UDMA/100
ata7.01: configured for UDMA/33
scsi 8:0:0:0: Direct-Access     ATA      ST3120022A       3.06 PQ: 0 ANSI: 5
sd 8:0:0:0: [sdd] 234441648 512-byte hardware sectors (120034 MB)
sd 8:0:0:0: [sdd] Write Protect is off
sd 8:0:0:0: [sdd] Mode Sense: 00 3a 00 00
sd 8:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 8:0:0:0: [sdd] 234441648 512-byte hardware sectors (120034 MB)
sd 8:0:0:0: [sdd] Write Protect is off
sd 8:0:0:0: [sdd] Mode Sense: 00 3a 00 00
sd 8:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sdd: sdd1
sd 8:0:0:0: [sdd] Attached SCSI disk
sd 8:0:0:0: Attached scsi generic sg3 type 0
scsi 8:0:1:0: CD-ROM            HL-DT-ST DVDRAM GSA-H10N  JL12 PQ: 0 ANSI: 5
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray

UDMA/33 on the burner should be ok for 48x (150x48 = 7.2 MB/s) ?
Or just 16x, as I read elsewhere ?

TIA

-- 
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2008.1 (Cooker) for i586
Linux 2.6.23-jam05 (gcc 4.2.2 20071128 (4.2.2-2mdv2008.1)) SMP PREEMPT

Re: Again... DMA speed too slow

[Andrew Morton]

On Sun, 30 Mar 2008 23:53:57 +0200 "J.A. Magallón" <jamagallon@ono.com> wrote:

> Hi all...
> 
> I have tried to burn some data from the commandline with wodim (since time
> ago I just used beasero...), and I have noticed this (media is CD, not DVD):
> 
> Vendor_info    : 'HL-DT-ST'
> Identification : 'DVDRAM GSA-H10N '
> Revision       : 'JL12'
> Device seems to be: Generic mmc2 DVD-R/DVD-RW.
> Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
> Driver flags   : MMC-3 SWABAUDIO BURNFREE
> Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
> Speed set to 8467 KB/s
> wodim: DMA speed too slow (OK for 5x). Cannot write at speed 48x.
> Starting to write CD/DVD at speed  48.0 in real TAO mode for single session.
> 
> I just can burn CDs at 5x ??
> But then the program tries to write at 48x.
> It the DMA message really true ?
> 
> Accodring to wodim -prcap:
> 
>   Maximum read  speed: 22161 kB/s (CD 125x, DVD 16x)
>   Current read  speed: 22161 kB/s (CD 125x, DVD 16x)
>   Maximum write speed: 11080 kB/s (CD  62x, DVD  8x)
>   Current write speed: 11080 kB/s (CD  62x, DVD  8x)
>   Rotational control selected: CLV/PCAV
>   Buffer size in KB: 2048
>   Copy management revision supported: 1
>   Number of supported write speeds: 3
>   Write speed # 0: 11080 kB/s CLV/PCAV (CD  62x, DVD  8x)
>   Write speed # 1:  5540 kB/s CLV/PCAV (CD  31x, DVD  4x)
>   Write speed # 2:  3324 kB/s CLV/PCAV (CD  18x, DVD  2x)
> 
> Why the tests in wodim say that DMA to the drive is slow ?
> 
> Kernel is 2.6.24.4.
> The drive is controlled by libata+sata_promise:
> 
> sata_promise 0000:03:04.0: version 2.11
> ACPI: PCI Interrupt 0000:03:04.0[A] -> GSI 23 (level, low) -> IRQ 17
> scsi6 : sata_promise
> scsi7 : sata_promise
> scsi8 : sata_promise
> ata5: SATA max UDMA/133 mmio m4096@0xf6029000 port 0xf6029200 irq 17
> ata6: SATA max UDMA/133 mmio m4096@0xf6029000 port 0xf6029280 irq 17
> ata7: PATA max UDMA/133 mmio m4096@0xf6029000 port 0xf6029300 irq 17
> ata5: SATA link down (SStatus 0 SControl 300)
> ata6: SATA link down (SStatus 0 SControl 0)
> ata7.00: ATA-6: ST3120022A, 3.06, max UDMA/100
> ata7.00: 234441648 sectors, multi 0: LBA48
> ata7.01: ATAPI: HL-DT-ST DVDRAM GSA-H10N, JL12, max UDMA/33
> ata7.00: configured for UDMA/100
> ata7.01: configured for UDMA/33
> scsi 8:0:0:0: Direct-Access     ATA      ST3120022A       3.06 PQ: 0 ANSI: 5
> sd 8:0:0:0: [sdd] 234441648 512-byte hardware sectors (120034 MB)
> sd 8:0:0:0: [sdd] Write Protect is off
> sd 8:0:0:0: [sdd] Mode Sense: 00 3a 00 00
> sd 8:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
> sd 8:0:0:0: [sdd] 234441648 512-byte hardware sectors (120034 MB)
> sd 8:0:0:0: [sdd] Write Protect is off
> sd 8:0:0:0: [sdd] Mode Sense: 00 3a 00 00
> sd 8:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
>  sdd: sdd1
> sd 8:0:0:0: [sdd] Attached SCSI disk
> sd 8:0:0:0: Attached scsi generic sg3 type 0
> scsi 8:0:1:0: CD-ROM            HL-DT-ST DVDRAM GSA-H10N  JL12 PQ: 0 ANSI: 5
> sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
> 
> UDMA/33 on the burner should be ok for 48x (150x48 = 7.2 MB/s) ?
> Or just 16x, as I read elsewhere ?
> 

Please always cc linux-ide on ata-related bug reports.

Re: Again... DMA speed too slow

[Tejun Heo]

Andrew Morton wrote:
> On Sun, 30 Mar 2008 23:53:57 +0200 "J.A. Magallón" <jamagallon@ono.com> wrote:
> 
>> Hi all...
>>
>> I have tried to burn some data from the commandline with wodim (since time
>> ago I just used beasero...), and I have noticed this (media is CD, not DVD):
>>
>> Vendor_info    : 'HL-DT-ST'
>> Identification : 'DVDRAM GSA-H10N '
>> Revision       : 'JL12'
>> Device seems to be: Generic mmc2 DVD-R/DVD-RW.
>> Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
>> Driver flags   : MMC-3 SWABAUDIO BURNFREE
>> Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
>> Speed set to 8467 KB/s
>> wodim: DMA speed too slow (OK for 5x). Cannot write at speed 48x.
>> Starting to write CD/DVD at speed  48.0 in real TAO mode for single session.
>>
>> I just can burn CDs at 5x ??
>> But then the program tries to write at 48x.
>> It the DMA message really true ?

Which controller are you on?  I bet the recording itself will work fine 
on 48x.  It's probably that READ/WRITE BUFFERs are executed using PIO 
for compatibility reasons.

-- 
tejun