Re: Write error - SATA link reset with growisofs and tracksize not multiple of 32kB
Zitat von Andy Polyakov <[EMAIL PROTECTED]>: There is only one conclusion one can draw: your firmware apparently hangs in last non-padded write command. It might be that it would hang in recording modes other than DAO, but growisofs won't exhibit it, because it pads data to nearest ECC block boundary in all recording modes, but DAO. For this reason the problem is described as "LG GH20NS10 might hang at the end of DVD-R[W] DAO recording" at http://fy.chalmers.se/~appro/linux/DVD+RW/hcn.html. Your text describes the problem very well. For my reference could you submit first line of 'dvd+rw-mediainfo /dev/scd0' output? It contains INQUIRY result. A. dvd+rw-mediainfo /dev/scd0 INQUIRY:[HL-DT-ST][DVDRAM GH20NS10 ][EL01] Thanks again Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Write error - SATA link reset with growisofs and tracksize not multiple of 32kB
Andy Polyakov <[EMAIL PROTECTED]> wrote:
It apparently times out, which is basically why I thought of "Short DAO
recordings."
Could you test following. Open growisofs_mmc.cpp in text editor, locate
line that reads
cmd.timeout(dao_toggle?180:60);
Modify it as
cmd.timeout(180);
Recompile and retry recording. If it still times out, try to increase to
say 300.
I tried it - no better. I just have to wait longer for the Error to
occur. With 300 growisofs is writing:
587497472/587524096 (100.0%) @0.0x, remaining 0:00 RBU 0.1% UBU 100.0%
for approximately 5 Minutes, then Kernel logs the link reset and I get
the error.
One interesting thing: The drive blinks for about 1-2 minutes after
the first 100%-line. Then it comes short into action (noise like spin
up/down) and the LED on the drives goes out. It seems to have
finished. But you have to wait for another few minutes until growisofs
stops with error. As said above, kernel messages also appear only at
the end of the wait time.
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.
Well, I'd bet the values are from different recordings, because
discrepancy is simply insane. It's as important as to maintain sanity:-)
Ok, to maintain sanity :-) : You were right. The correct kernel-log
for the 0.5G-Testfile is:
-
[ 1656.664046] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action
0x6 frozen
[ 1656.664067] ata2.00: cmd a0/01:00:00:00:80/00:00:00:00:00/a0 tag 0
dma 32768 out
[ 1656.664070] cdb 2a 00 00 04 60 90 00 00 0d 00 00 00 00 00 00 00
[ 1656.664072] res 40/00:03:00:00:80/00:00:00:00:00/a0 Emask
0x4 (timeout)
[ 1656.664077] ata2.00: status: { DRDY }
[ 1656.664084] ata2: hard resetting link
[ 1663.204032] ata2: link is slow to respond, please be patient (ready=0)
[ 1666.681520] ata2: softreset failed (device not ready)
[ 1666.681546] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1671.681523] ata2.00: qc timeout (cmd 0xa1)
[ 1671.681543] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 1671.681548] ata2.00: revalidation failed (errno=-5)
[ 1671.681557] ata2: hard resetting link
[ 1678.212027] ata2: link is slow to respond, please be patient (ready=0)
[ 1681.684035] ata2: softreset failed (device not ready)
[ 1681.684061] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1691.685542] ata2.00: qc timeout (cmd 0xa1)
[ 1691.685564] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 1691.685569] ata2.00: revalidation failed (errno=-5)
[ 1691.685577] ata2: hard resetting link
[ 1692.168030] ata2: softreset failed (device not ready)
[ 1692.168041] ata2: failed due to HW bug, retry pmp=0
[ 1692.333545] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 1692.339886] ata2.00: configured for UDMA/100
[ 1692.339936] ata2: EH complete
---
With "04 60 90" as the correct failing LBA-Adress.
I don't know which test the other kernel log was from.
Too complicated:-) Open growisofs_mmc.cpp in text editor and locate
function named minus_r_reserve_track. In the beginning it reads
if (is_dao) dao_blocks = blocks;
Replace this line with
if (0) dao_blocks = blocks;
A.
This does the trick in my case. Burns without problems. So I can stay
with growisofs and don't have to try all different burning programs.
(and such a simple one - could have searched for eternity to find it).
Nevertheless if you think it's worth (still no other complained about
the same error) and if you have additional ideas, I could make further
testing.
Otherwise we could close this thread. Many thanks for your help!
Markus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Write error - SATA link reset with growisofs and tracksize not multiple of 32kB
Hi Jörg, [EMAIL PROTECTED] wrote: Hi, 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: This problem is well known with the LG drive. Cdrecord added a workaround ~2 2 months ago. I "googled" for hours and couldn't find any posting or documentation reffering to this problem. Do you have any further information about it? Is it definitely a bug of this modell? Has anybody tried to get a firmware-fix from LG? Markus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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. :-[ [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." 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Write error - SATA link reset with growisofs and tracksize not multiple of 32kB
Hi,
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
/dev/scd0: "Current Write Speed" is 4.1x1352KBps.
0/587524096 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
0/587524096 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
0/587524096 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
0/587524096 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
0/587524096 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
0/587524096 ( 0.0%) @0x, remaining ??:?? RBU 100.0% UBU 0.0%
16646144/587524096 ( 2.8%) @3.6x, remaining 13:43 RBU 100.0% UBU 85.3%
35160064/587524096 ( 6.0%) @4.0x, remaining 7:19 RBU 99.9% UBU 100.0%
53641216/587524096 ( 9.1%) @4.0x, remaining 5:08 RBU 100.0% UBU 100.0%
72122368/587524096 (12.3%) @4.0x, remaining 4:10 RBU 100.0% UBU 100.0%
90636288/587524096 (15.4%) @4.0x, remaining 3:28 RBU 99.9% UBU 100.0%
[...]
534609920/587524096 (91.0%) @4.0x, remaining 0:11 RBU 100.0% UBU 100.0%
553123840/587524096 (94.1%) @4.0x, remaining 0:07 RBU 100.0% UBU 100.0%
571604992/587524096 (97.3%) @4.0x, remaining 0:03 RBU 47.5% UBU 100.0%
587497472/587524096 (100.0%) @3.4x, 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%
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%
[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)
[ 6030.669581] ata2.00: status: { DRDY }
[ 6030.669589] ata2: hard resetting link
[ 6037.200029] ata2: link is slow to respond, please be patient (ready=0)
[ 6040.672036] ata2: softreset failed (device not ready)
[ 6040.672061] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 6045.672181] ata2.00: qc timeout (cmd 0xa1)
[ 6045.672204] ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 6045.672209] ata2.00: revalidation failed (errno=-5)
[ 6045.672218] ata2: hard resetting link
[...]
[ 6105.680071] ata2.00: disabled
[ 6105.680091] ata2: exception Emask 0x40 SAct 0x0 SErr 0x800 action
0x6 frozen t4
[ 6105.680097] ata2: SError: { HostInt }
[ 6105.680104] ata2: hard resetting link
[ 6112.212025] ata2: link is slow to respond, please be patient (ready=0)
[ 6115.684025] ata2: softreset failed (device not ready)
[ 6115.684049] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 6115.684086] ata2: EH complete
---
(Board: Gigabyte GA-MA78G-DS3H with AMD780G Chipset)
The DVD is readable afterwards, and a "dd" gives me the complete image
size (not only the bytes reported as successfull written). But the
error is annoying.
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. Could it be a defect drive or a bug of the
SATA-Chipset?
Would it be a good idea to patch growisofs and make sure that
tracksize is automatically extended to the next 32kB? Or could this
lead to other problems?
Regards
Markus
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
