I have a problem with my SATA-drive LG GH20NS10 (actual firmware EL01,
same with old firmware) and growisofs (7.1):
If I try to burn a DVD-Image on a DVD-R (or quick-blanked DVD-RW) in
DAO-Mode with a size not divisible by 32kB, writing stops after the last
complete 32kB-Block and I get an write error:
--------------------
growisofs -dvd-compat -Z /dev/scd0=test2.iso
Executing 'builtin_dd if=test2.iso of=/dev/scd0 obs=32k seek=0'
/dev/scd0: FEATURE 21h is not on, engaging DAO...
/dev/scd0: reserving 286877 block, warning for short DAO recording
Does it fail in same way if recording is larger than 750MB, preferably
~1GB? Look up "Short DAO recordings with Pioneer units" at
http://fy.chalmers.se/~appro/linux/DVD+RW/hcn.html. What I'm implying is
that you might suffer from something similar when DAO recording is not
divisible by 32KB. A firmware bug might be triggered in this case.
[...]
[repeating]
587497472/587524096 (100.0%) @0.0x, remaining 0:00 RBU 0.1% UBU 100.0%
587497472/587524096 (100.0%) @0.0x, remaining 0:00 RBU 0.1% UBU 100.0%
587497472/587524096 (100.0%) @0.0x, remaining 0:00 RBU 0.1% UBU 100.0%
587497472/587524096 (100.0%) @0.0x, remaining 0:00 RBU 0.1% UBU 100.0%
:-[ [EMAIL PROTECTED] failed with SK=0h/ASC=00h/ACQ=03h]: Input/output error
:-( write failed: Input/output error
----------------------
at the same time, kernel logs:
---------------------
[ 6030.669547] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
[ 6030.669568] ata2.00: cmd a0/01:00:00:00:80/00:00:00:00:00/a0 tag 0
dma 32768 out
[ 6030.669570] cdb 2a 00 00 01 db 40 00 00 0e 00 00 00 00 00
00 00
[ 6030.669573] res 40/00:03:00:00:80/00:00:00:00:00/a0 Emask
0x4 (timeout)
It apparently times out, which is basically why I thought of "Short DAO
recordings."
With -use-the-force-luke=tracksize:XYZ and XYZ divisible by 16 (=32kB
blocks), it works without error.
My other drive (Optiarc DVD RW AD-7170A, IDE - not SATA) doesn't have
this problem, I haven't found other problems with the LG-drive and I
haven't found any problems like this in the internet.
Is there a explanation for the behaviour? As far as I understand, DVD-R
can only be written in 32kB-Blocks, but the drive itself should fill up
incomplete blocks.
Yes, it should. But "should" does not necessarily equivalent to "does,"
does it?
Could it be a defect drive or a bug of the SATA-Chipset?
I'd say it's more likely to be a firmware bug, than hardware defect or
SATA problem.
Would it be a good idea to patch growisofs and make sure that tracksize
is automatically extended to the next 32kB?
Well, originally growisofs was unconditionally padding everything, but
in version 6.1 an exclusion was made for DAO recording. This was
requested by user[s] [I think it was through K3b] for more accurate
media duplication.
Or could this lead to other problems?
There are naturally two ways to *attempt* to work around the problem:
1. RESERVE TRACK for non-divisible-by-16 amount and then transfer padded
last block.
2. RESERVE TRACK for padded amount of data and transfer padded data.
Option #1 is in formal specification violation, yet might work in *your*
unit, but would *not* in number of others (it's tested). Option #2 would
upset users who requested this feature in according with what
specification promises. In other words, the answer is "no" to previous
question. What one can discuss is to document this case at
http://fy.chalmers.se/~appro/linux/DVD+RW/hcn.html and maybe a new
command-line option so that you don't have to calculate XYZ yourself. A.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
