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:[EMAIL PROTECTED] Sent: Tuesday, January 20, 2004 8:15 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Sony DRU-510A, cannot burn dvd's on Solaris9 x386 >From [EMAIL PROTECTED] 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:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
