| 1 |
On Fri, Nov 20, 2009 at 04:48:25PM +0100, Joerg Schilling wrote: |
| 2 |
> José Romildo Malaquias <j.romildo@×××××.com> wrote: |
| 3 |
> |
| 4 |
> > > There was a report for broken Pioneer formware that hits in -v mode and |
| 5 |
> > > causes the firmware from the drive to through away the data before writing |
| 6 |
> > > it to the medium. |
| 7 |
> > |
| 8 |
> > Do you mean a test without -V or -v ? |
| 9 |
> |
| 10 |
> Without -v, as in this case cdrecord does not read the drives buffer fill ratio. |
| 11 |
> It seems that there is a bug in Pioneer firmware that is triggered by calling |
| 12 |
> SCSI get buffer cap (0x5C)and that results in throwing away the DMA data. |
| 13 |
|
| 14 |
Good news! |
| 15 |
|
| 16 |
With the command (without using the -v option) |
| 17 |
|
| 18 |
$ script -f -c "cdrecord -V debug=2 -sao -eject speed=8 fs=256m driveropts=burnfree /var/tmp/image.iso" cdrecord.log |
| 19 |
|
| 20 |
cdrecord completed successfully. The sha1 sums (calculated in a |
| 21 |
different computer) for both the image and the recorded media are |
| 22 |
identical! |
| 23 |
|
| 24 |
The compressed output of the cdrecord command is attached. |
| 25 |
|
| 26 |
Should I conclude that the firmware of the unit is affected by the same |
| 27 |
bug found in that Pioneer one? |
| 28 |
|
| 29 |
Is it fixable? |
| 30 |
|
| 31 |
I was not able to find any firmware update for my unit. |
| 32 |
|
| 33 |
Romildo |
Archives