Re: Write error - SATA link reset with growisofs and tracksize not multiple of 32kB
Hi Andy,
many thanks for the reply - sorry for answering late.
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.
Maybe a bad example. But I tried it explicitely with 0.5GB, 1GB and
1.5GB. Every time the same. In further testing I focused on the 0.5GB
because it's faster ;-).
So the "short DAO recording" is definitely not the problem.
:-[ 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."
For your question about the kernel-Log in later mail:
As far as I remember, the kernel output belongs to this recording, but
I'm not 100% sure. If you think it's important, I will test it again.
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?
No it doesn't - just wanted to make sure, that it "should".
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.
Jörg mentioned in the other reply, that this problem is well known
with the drive and cdrecord already implemented a fix. But nobody
seems to have documented this in public.
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.
Thanks for the explanation. I wondered why the padding was removed
with 6.1. but the argument with "more accurate media duplication"
seems to be reasonable.
As long as I'm the only one with this problem, an official patch or
commandline option would be overstated.
I was thinking about patching the code for myself (maybe buying a new
drive would be less effort ;-) ): Just round "tracksize" up to the
next 32k-Block in adding something like
tracksize=(tracksize+DVD_BLOCK-1)/DVD_BLOCK * DVD_BLOCK to the lines:
tracksize = dao_size ? (dao_size*CD_BLOCK) : sb.st_size;
and
tracksize=from_733(descr->volume_space_size)*CD_BLOCK;
Do you think, that's too crude, even for a "personal" patch?
Markus
Reply to: