RE: Sony DRU-510A, cannot burn dvd's on Solaris9 x386
seeming that my woe may stem from the drive itself I swapped out drives with
a Pioneer DVR-A06U.
trying serveral methods of burning both with dvd-r and dvd+r media, I'm
getting the same results. Below is output from one burn test, -dao flag
thrown, but I can say this .. I get the same results pretty much with any
flags I throw.
cdrecord -v -dao dev=1,0,0 speed=2 /var/system/win32ahc.iso
Cdrecord-ProDVD-Clone 2.01a12 (i386-pc-solaris2.9) Copyright (C) 1995-2003
Jörg
Schilling
Unlocked features: ProDVD Clone
Limited features:
This copy of cdrecord is licensed for:
private/research/educational_non-commerci
al_use
TOC Type: 1 = CD-ROM
scsidev: '1,0,0'
scsibus: 1 target: 0 lun: 0
Warning: Using USCSI interface.
Using libscg version 'schily-0.7'
atapi: 1
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'PIONEER '
Identifikation : 'DVD-RW DVR-106D'
Revision : '1.07'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: DVD+R
Profile: DVD+R (current)
Profile: DVD+RW
Profile: DVD-RW sequential overwrite
Profile: DVD-RW restricted overwrite
Profile: DVD-R sequential recording
Profile: DVD-ROM
Profile: CD-RW
Profile: CD-R
Profile: CD-ROM
Using generic SCSI-3/mmc-3 DVD+R driver (mmc_dvdplusr).
Driver flags : DVD MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 1605632 = 1568 KB
FIFO size : 4194304 = 4096 KB
Track 01: data 792 MB
Total size: 792 MB = 405716 sectors
Current Secsize: 2048
Blocks total: 2295104 Blocks current: 2295104 Blocks remaining: 1889388
Starting to write CD/DVD at speed 2 in real SAO mode for single session.
Last chance to quit, starting real write 0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
Starting new track at sector: 0
Track 01: 1 of 792 MB written (fifo 98%) [buf 67%] 2.4x.cdrecord:
I/O er
ror. write_g1: scsi sendcmd: no error
CDB: 2A 00 00 00 03 07 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 21 02 00 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0
Sense flags: Blk 0 (not valid)
resid: 63488
cmd finished after 0.006s timeout 100s
write track data: error after 1587200 bytes
cdrecord: The current problem looks like a buffer underrun.
cdrecord: Try to use 'driveropts=burnfree'.
cdrecord: Make sure that you are root, enable DMA and check your HW/OS set
up.
Writing time: 30.634s
Average write speed 19.6x.
Fixating...
cdrecord: I/O error. close track/session: scsi sendcmd: no error
CDB: 5B 01 01 00 00 FF 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 24 00 00 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 5.010s timeout 1000s
cdrecord: I/O error. close track/session: scsi sendcmd: no error
CDB: 5B 01 06 00 00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 72 03 00 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x72 Qual 0x03 (session fixation error - incomplete track in
session
) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.005s timeout 1000s
Fixating time: 5.027s
cdrecord: fifo had 89 puts and 26 gets.
cdrecord: fifo was 0 times empty and 8 times full, min fill was 95%.
-----Original Message-----
From: Joerg Schilling [mailto:schilling@fokus.fraunhofer.de]
Sent: Tuesday, January 20, 2004 8:15 AM
To: appro@fy.chalmers.se; schilling@fokus.fraunhofer.de
Cc: carl.bonvini@ps.inficon.com; cdwrite@other.debian.org; pav@oook.cz
Subject: Re: Sony DRU-510A, cannot burn dvd's on Solaris9 x386
>From appro@fy.chalmers.se Tue Jan 20 01:00:19 2004
>> >> from all the tests I've run .. I know it's a buffer overrun.
>>
>> >Buffer overruns are *not* denoted with "INVALID ADDRESS FOR WRITE," and
>> >should be handled by application transparently. *Unhandled* buffer
>> >underruns in turn *are* denoted as depicted in originating post. How do
>> >you come to the conclusion that it's overrun condition?
>>
>> This is definitely wrong!
>Can you be so kind and tell what exactly is "definitely wrong"? Given
>that "definitely wrong" implies "complete opposite is true". Do you mean
>that "buffer *overruns* are denoted with "INVALID ADDRESS FOR WRITE"? Or
>do you mean that "buffer *overruns* are not handled by cdrecord-ProDVD
>transparently"? Or do you mean that "*underruns* are never denoted as
>depicted in originating post"? I can agree that my *last* statement can
>be classified as "slightly wrong", as "buffer *underrun *can be* denoted
>as depicted in originating post" is more appropriate than "buffer
>*underrun* *is* denoted." But I can't agree that all of the above is
>"definitely wrong."
I am as verbose as you have been.....
It is obvious that "INVALID ADDRESS FOR WRITE" is a possible
result of a buffer underun.
I don't know what you mean by handling buffer underrun transparently in an
application?
>> It is relatively easy to prove the oposite!
>What is easy to refute? That "buffer underrun protection can't be
>switched off in DVD+? Or that "support for buffer underrun protection is
>mandatory for Incremental mode"? Or that "buffer underrun protection is
>optional in DAO mode"?
Burn proof can be switched on for DVD-
Please tell me why you are constantly writing wrong things trying people
to convince that DAO mode is worse then the packet Mode used by DVD+?
If you don't know enough about the behaviour of DVD- drives just stay
silent.
It is simple to prove that e.g. Pioneer and Toshiba drives have a well
working buffer underrun protection for DVD- in DAO.
>> My tests with burnproof active did show that it works for DVD SAO
writing.
>We have discussed this already. My experiments with initial SONY 500
>firmware has shown opposite, at least with real(!) recording. It most
Well, then the Sony just has a broken firmware. Why should there
be a buffer underrun protection mechanism if not to exactly protect
against the only write mode that would suffer from BUs?
>> The recording strategy used by growisofs gives less compatibility as
>> it does not write in SAO mode.
>We have discussed it too. Being way more practical Incremental strategy
>provides for *adequate* compatibility. I have not recieved a single
>report that media recorded in Incremental mode was less compatible that
>one recorded in DAO. A.
If you admid that we didcussed this already, why then do you constantly
insist
in writing that growisofs is better?
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353
Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling
ftp://ftp.berlios.de/pub/schily
Reply to: