1 |
On Sun, Nov 29, 2009 at 06:58:40PM +0100, Joerg Schilling wrote: |
2 |
> José Romildo Malaquias <j.romildo@×××××.com> wrote: |
3 |
> |
4 |
> > On Fri, Nov 20, 2009 at 04:48:25PM +0100, Joerg Schilling wrote: |
5 |
> > > José Romildo Malaquias <j.romildo@×××××.com> wrote: |
6 |
> > > |
7 |
> > > > > There was a report for broken Pioneer formware that hits in -v mode and |
8 |
> > > > > causes the firmware from the drive to through away the data before writing |
9 |
> > > > > it to the medium. |
10 |
> > > > |
11 |
> > > > Do you mean a test without -V or -v ? |
12 |
> > > |
13 |
> > > Without -v, as in this case cdrecord does not read the drives buffer fill ratio. |
14 |
> > > It seems that there is a bug in Pioneer firmware that is triggered by calling |
15 |
> > > SCSI get buffer cap (0x5C)and that results in throwing away the DMA data. |
16 |
> > |
17 |
> > Good news! |
18 |
> > |
19 |
> > With the command (without using the -v option) |
20 |
> > |
21 |
> > $ script -f -c "cdrecord -V debug=2 -sao -eject speed=8 fs=256m driveropts=burnfree /var/tmp/image.iso" cdrecord.log |
22 |
> > |
23 |
> > cdrecord completed successfully. The sha1 sums (calculated in a |
24 |
> > different computer) for both the image and the recorded media are |
25 |
> > identical! |
26 |
> |
27 |
> OK, could you please use an original cdrecord without your recent self made |
28 |
> patch and then apply this patch: |
29 |
[...] |
30 |
> This should avoid some calls to the buffer cap function before the drive's |
31 |
> internal buffer was filled the first time. |
32 |
> |
33 |
> Then please test again with -v |
34 |
|
35 |
It works. See attached the output of the command: |
36 |
|
37 |
# 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 |
38 |
|
39 |
Romildo |