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% :-[ WRITE@LBA=46090h 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.