[gentoo-user] cdrecord fails to burn dvd
José Romildo Malaquias
Burning dvds with Cdrecord-ProDVD-ProBD-Clone 2.01.01a67 on my Dell
Vostro 1510 notebook is always failing.
The device is identified as TEAC DVD+-RW DVW28SLC and can write at 8x
speed.
The process starts and reports writing at 14.5x, but the media is not
burnt. cdrecord reaches but does not finish the fixation stage. It
reports an average write speed of 14.3x. When I manage to stop the
process (by rebooting the computer), I see the media has not been burnt
and it is not ruined. It can be reused.
With cdrkit, cdrecord finishes (after using different speeds, as 2x, 1x,
4x, 6x e 20x), but when reading the disc an input/output error is
reported.
With Nero Linux I can burn dvd discs without problems, though.
When I bought this notebook in january and first installed gentoo,
cdrecord used to work. Then at some point ago (probably after some
update) it has stopped working with the behaviour I have described
above. But by then I did not have the time to investigate, and keep
using only Nero, which continues to work well. Today I decided to
investigate a little more the problem, but could not reach to any
conclusions.
Any clues?
Romildo
Joerg Schilling
> Hello.
>
> Burning dvds with Cdrecord-ProDVD-ProBD-Clone 2.01.01a67 on my Dell
> Vostro 1510 notebook is always failing.
>
> The device is identified as TEAC DVD+-RW DVW28SLC and can write at 8x
> speed.
>
> The process starts and reports writing at 14.5x, but the media is not
> burnt. cdrecord reaches but does not finish the fixation stage. It
> reports an average write speed of 14.3x. When I manage to stop the
> process (by rebooting the computer), I see the media has not been burnt
> and it is not ruined. It can be reused.
>
> With cdrkit, cdrecord finishes (after using different speeds, as 2x, 1x,
> 4x, 6x e 20x), but when reading the disc an input/output error is
> reported.
wodim is known for not being able to support DVDs.
If you like to get help with cdrecord, I recommend you to first send information
and log files about your problem.
I need the following:
The version number of cdrecord that caused the bug.
The command line that was used for the failing command.
The complete output (including error messages) from 'cdrecord -v ...' (use
"script" to fetch the output)
Probably the important part of the 'cdrecord -V' output if we agreed on it
The OS name, release and hardware (processor)
Special conditions of your environment (libc vers. SCSI transport ...)
Sufficient information on the media used. This is at least the ATIP data, a
note to CD-R/CD-RW and information on the state and the case history of this
media.
If cdrecord reports a higher speed than possible, I would guess that the Linux
kernel does not set up DMA correctly.
J�rg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
joerg.s...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
José Romildo Malaquias
Most of the requested information can be found in the attached log file.
I do not know how to get the ATIP data on the media used. But I can say
that I have recently used more than 200 discs of this brand (Kodak) and
it has shown very reliable. cdrecord has no problems with it on my
desktop computer. The problem happens just in my notebook. Therefore it
suggests the problem is not with the media.
If you need any more information, just ask.
Romildo
José Romildo Malaquias
> On Sun, Nov 08, 2009 at 05:35:50PM +0100, Joerg Schilling wrote:
> > Jos� Romildo Malaquias <j.ro...@gmail.com> wrote:
> > > Burning dvds with Cdrecord-ProDVD-ProBD-Clone 2.01.01a67 on my Dell
> > > Vostro 1510 notebook is always failing.
> > I need the following:
[...]
> > Sufficient information on the media used. This is at least the ATIP
> > data, a note to CD-R/CD-RW and information on the state and the case
> > history of this media.
> I do not know how to get the ATIP data on the media used. But I can say
> that I have recently used more than 200 discs of this brand (Kodak) and
> it has shown very reliable. cdrecord has no problems with it on my
> desktop computer. The problem happens just in my notebook. Therefore it
> suggests the problem is not with the media.
Attached is information related to the ATIP of the media, get with
cdrecod and dvd+rw-mediainfo.
Romildo
Joerg Schilling
> Most of the requested information can be found in the attached log file.
>
> I do not know how to get the ATIP data on the media used. But I can say
Call cdrecord -atip
For the medium state, I would need the output from cdrecord -minfo
before and after you tries to burn.
> that I have recently used more than 200 discs of this brand (Kodak) and
> it has shown very reliable. cdrecord has no problems with it on my
> desktop computer. The problem happens just in my notebook. Therefore it
> suggests the problem is not with the media.
Did you ever write a DVD-R with this hardware?
José Romildo Malaquias
> Jos� Romildo Malaquias <j.ro...@gmail.com> wrote:
>
>
> > Most of the requested information can be found in the attached log file.
> >
> > I do not know how to get the ATIP data on the media used. But I can say
>
> Call cdrecord -atip
By searching the cdrecord man page I have found it. Thanks anyway.
> For the medium state, I would need the output from cdrecord -minfo
> before and after you tries to burn.
>
>
> > that I have recently used more than 200 discs of this brand (Kodak) and
> > it has shown very reliable. cdrecord has no problems with it on my
> > desktop computer. The problem happens just in my notebook. Therefore it
> > suggests the problem is not with the media.
>
> Did you ever write a DVD-R with this hardware?
Yes I have written some DVD-R discs with this hardware. When I bought
the notebook and installed gentoo in last January, burning with cdrecord
(from cdrtools) used to work. Sometime later (about one month, but I am
not sure) it stopped working. Probably after some upgrade. I do not
remeber exactly. By then I could not look at the problem because of lack
of time. Since then I have been using Nero Linux for recording DVD-R
discs without problems.
Some information I have sent in previous messages may not be accurate
enough because I have forgotten to change the media to a new unused
one. So I am attaching a new file with the output of some requested
commands.
Romildo
Joerg Schilling
With the messages you send, it cannot be cdrecord but either your drive
or the Linux kernel.
One interesting point is that cdrecord is unable to do a DMA speed test.
THis may have different reasons and without knowing the reason, I cannot
say more...
You may try to call cdrecord -v -checkdrive -V
and have a look at the SCSI read buffer command.
You also may try to reduce the transfer size to 16 kb by adding "ts=16k"
to the command line in hope that it is a driver bug that goes away with smaller
transfer sizes.
Joerg Schilling
> > You may try to call cdrecord -v -checkdrive -V
> >
> > and have a look at the SCSI read buffer command.
>
> Unfortanatly I do not know how to deal with the output of the above
> command. So I am attaching it here (cdrecord0.log) and maybe someaone
> can find anything unexpected in it.
>
OK, the drive does not support the read buffer command, this is why cdrecord
cannot do a DMA speed test.
But you have a massive problem in the linux kernel that needs to be
investigated. The test unit ready command _cannot_ return a "fatal"
SCSI transport error as long as there is a drive connected.
Please start with running the "scgcheck" command to get some informations
on the compliance problems in your linux kernel.
José Romildo Malaquias
> Jos� Romildo Malaquias <j.ro...@gmail.com> wrote:
> OK, the drive does not support the read buffer command, this is why cdrecord
> cannot do a DMA speed test.
>
> But you have a massive problem in the linux kernel that needs to be
> investigated. The test unit ready command _cannot_ return a "fatal"
> SCSI transport error as long as there is a drive connected.
>
> Please start with running the "scgcheck" command to get some informations
> on the compliance problems in your linux kernel.
The output of scgcheck is attached to this message.
Romildo
Joerg Schilling
To find the reason for the following "Impossible" because
illegal error situation:
Executing 'test unit ready' command on Bus 0 Target 6, Lun 0 timeout 40s
CDB: 00 00 00 00 00 00
cdrecord: Input/output error. test unit ready: scsi sendcmd: fatal error
CDB: 00 00 00 00 00 00
cmd finished after 0.000s timeout 40s
please run the command again and add debug=2 to the list of options.
Joerg Schilling
> On Mon, Nov 16, 2009 at 03:43:12PM +0100, Joerg Schilling wrote:
> > Jos� Romildo Malaquias <j.ro...@gmail.com> wrote:
> >
> > To find the reason for the following "Impossible" because
> > illegal error situation:
> >
> > Executing 'test unit ready' command on Bus 0 Target 6, Lun 0 timeout 40s
> > CDB: 00 00 00 00 00 00
> > cdrecord: Input/output error. test unit ready: scsi sendcmd: fatal error
> > CDB: 00 00 00 00 00 00
> > cmd finished after 0.000s timeout 40s
> >
> >
> > please run the command again and add debug=2 to the list of options.
>
> I am attaching the compressed output of the command:
>
> script -f -c "cdrecord -v debug=2 -sao -eject speed=8 fs=256m driveropts=burnfree /var/tmp/image.iso" cdrecord.log
I cannot see any problem like the problem above.
BTW: this may be caused by the fact that you did not simply add debug=2
but at the same time removed -V.
Joerg Schilling
> > BTW: this may be caused by the fact that you did not simply add debug=2
> > but at the same time removed -V.
>
> I have run the cdrecord command again, this time passing "-V" and "debug=2":
>
> $ script -f -c "cdrecord -vvv -V debug=2 -sao -eject speed=8 fs=256m driveropts=burnfree /var/tmp/image.iso" cdrecord.log
>
> and the compressed log is attached.
>
> I hope you can find anything useful to understand what is happening.
I'll look at this later. Could you meanwhile do a test without -V please?
There was a report for broken Pioneer formware that hits in -v mode and
causes the firmware from the drive to through away the data before writing
it to the medium.
Joerg Schilling
> Jos� Romildo Malaquias <j.ro...@gmail.com> wrote:
>
> > > BTW: this may be caused by the fact that you did not simply add debug=2
> > > but at the same time removed -V.
> >
> > I have run the cdrecord command again, this time passing "-V" and "debug=2":
> >
> > $ script -f -c "cdrecord -vvv -V debug=2 -sao -eject speed=8 fs=256m driveropts=burnfree /var/tmp/image.iso" cdrecord.log
> >
> > and the compressed log is attached.
> >
> > I hope you can find anything useful to understand what is happening.
>
> I'll look at this later. Could you meanwhile do a test without -V please?
Sorry - I mean wihtout -v
With -v, crecord calls "read buffer cap" and this may cause a firmware bug in
your drive.
José Romildo Malaquias
> Jos� Romildo Malaquias <j.ro...@gmail.com> wrote:
>
> > > BTW: this may be caused by the fact that you did not simply add debug=2
> > > but at the same time removed -V.
> >
> > I have run the cdrecord command again, this time passing "-V" and "debug=2":
> >
> > $ script -f -c "cdrecord -vvv -V debug=2 -sao -eject speed=8 fs=256m driveropts=burnfree /var/tmp/image.iso" cdrecord.log
> >
> > and the compressed log is attached.
> >
> > I hope you can find anything useful to understand what is happening.
>
> I'll look at this later. Could you meanwhile do a test without -V please?
>
> There was a report for broken Pioneer formware that hits in -v mode and
> causes the firmware from the drive to through away the data before writing
> it to the medium.
Do you mean a test without -V or -v ?
Romildo
Joerg Schilling
Without -v, as in this case cdrecord does not read the drives buffer fill ratio.
It seems that there is a bug in Pioneer firmware that is triggered by calling
SCSI get buffer cap (0x5C)and that results in throwing away the DMA data.
Joerg Schilling
> > > Do you mean a test without -V or -v ?
> >
> > Without -v, as in this case cdrecord does not read the drives buffer fill ratio.
> > It seems that there is a bug in Pioneer firmware that is triggered by calling
> > SCSI get buffer cap (0x5C)and that results in throwing away the DMA data.
>
> Good news!
>
> With the command (without using the -v option)
>
> $ script -f -c "cdrecord -V debug=2 -sao -eject speed=8 fs=256m driveropts=burnfree /var/tmp/image.iso" cdrecord.log
>
> cdrecord completed successfully. The sha1 sums (calculated in a
> different computer) for both the image and the recorded media are
> identical!
Then it seems that the drive developer is Pioneer. TEAC is out of normal
business sind 4 years but it may be that they are the OEM for drives developed
by Pioneer.
> Is it fixable?
Fixable would be updating the firmware in the drive.
As it seems that Pioneer drives are sold by many companies, it may be that I
need to find a suitable workaround for the bug.
Joerg Schilling
> On Fri, Nov 20, 2009 at 04:48:25PM +0100, Joerg Schilling wrote:
> > Jos� Romildo Malaquias <j.ro...@gmail.com> wrote:
> >
> > > > There was a report for broken Pioneer formware that hits in -v mode and
> > > > causes the firmware from the drive to through away the data before writing
> > > > it to the medium.
> > >
> > > Do you mean a test without -V or -v ?
> >
> > Without -v, as in this case cdrecord does not read the drives buffer fill ratio.
> > It seems that there is a bug in Pioneer firmware that is triggered by calling
> > SCSI get buffer cap (0x5C)and that results in throwing away the DMA data.
>
> Good news!
>
> With the command (without using the -v option)
>
> $ script -f -c "cdrecord -V debug=2 -sao -eject speed=8 fs=256m driveropts=burnfree /var/tmp/image.iso" cdrecord.log
>
> cdrecord completed successfully. The sha1 sums (calculated in a
> different computer) for both the image and the recorded media are
> identical!
OK, could you please use an original cdrecord without your recent self made
patch and then apply this patch:
------- cdrecord.c -------
--- /tmp/sccs.RvayQW So Nov 29 18:48:57 2009
+++ cdrecord.c So Nov 29 18:47:24 2009
@@ -2590,7 +2590,7 @@
if (fper >= 0)
printf(" (fifo %3d%%)", fper);
#ifdef BCAP
- if (bsize > 0) { /* buffer size known */
+ if (bsize > 0 && bytes > bsize) { /* buffer size known */
scgp->silent++;
per = (*dp->cdr_buffer_cap)(scgp, (long *)0, &bfree);
scgp->silent--;
This should avoid some calls to the buffer cap function before the drive's
internal buffer was filled the first time.
Then please test again with -v
daid kahl
the analysis of Joerg Schilling.
Given the issue appears resolved, I can't help myself:
> When I bought this notebook in january and first installed gentoo,
> cdrecord used to work. Then at some point ago (probably after some
> update) it has stopped working with the behaviour I have described
> above.
This is every single story of Gentoo and Linux in amazing brevity.
~daid
Marcus Wanner
>> When I bought this notebook in january and first installed gentoo,
>> cdrecord used to work. Then at some point ago (probably after some
>> update) it has stopped working with the behaviour I have described
>> above.
>>
>
> This is every single story of Gentoo and Linux in amazing brevity.
>
Marcus
Alan McKinnon
/s/Gentoo and Linux/software/
There you go. Fixed that for you.
--
alan dot mckinnon at gmail dot com
Joerg Schilling
> > Then please test again with -v
>
> It works. See attached the output of the command:
>
> # script -f -c "/var/tmp/CDRTOOLS/opt/schily/bin/cdrecord -v -sao -eject speed=8 fs=256m driveropts=burnfree /var/tmp/image.iso" /var/tmp/cdrecord.log
This is really good news and the -v output shows that the first 1-2 MB, there
is no display for the drive buffer fill ratio as cdrecord does not call read
buffer cap. I just released 2.01.01a69 at:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
that includes the change.
José Romildo Malaquias
> Jos� Romildo Malaquias <j.ro...@gmail.com> wrote:
>
> > > Then please test again with -v
> >
> > It works. See attached the output of the command:
> >
> > # script -f -c "/var/tmp/CDRTOOLS/opt/schily/bin/cdrecord -v -sao -eject speed=8 fs=256m driveropts=burnfree /var/tmp/image.iso" /var/tmp/cdrecord.log
>
> This is really good news and the -v output shows that the first 1-2 MB, there
> is no display for the drive buffer fill ratio as cdrecord does not call read
> buffer cap. I just released 2.01.01a69 at:
>
> ftp://ftp.berlios.de/pub/cdrecord/alpha/
>
> that includes the change.
>
> J�rg
I want to thank J�rg for his persistence in helping me to solve the
issue with my system. Thanks for his effort, and for the solution he has
found.
Romildo
Dale
When it comes to CD/DVD stuff, he's the man. He sort of reminds me of a
transmission commercial. If he can't fix it, then it ain't broke. lol
Dale
:-) :-)