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: Growisofs input cache (get away from dd?)
Hi, Bill Davidsen wrote: not passing multiple GB of once-used data through the system buffers and blowing everything else out. I see some effects which could make the O_DIRECT approach less superior to normal reading than your scenario would let expect: - If the (ISO) image is freshly generated then the formatter program just blew out everything else anyway. And for the ISO formatter it makes few sense to read O_DIRECT as it has a random access pattern on eventually small files. - The cache area in RAM is nowadays quite large and i understand that the least recently used cache chunks get thrown out. While a growisofs read chunk is ageing in the cache for several seconds, any busy process can refresh its own chunks' read time. So i expect that the cache of growisofs' input stream can only blow out chunks which are as fewly used as its own chunks. This would explain why i never saw the need to do O_DIRECT reading: my ISO images are fresh, if they are big. Typically they get piped directly into the burner process. I have one use case, though, where i burn two identical copies of the same DVD image for redundancy reasons. One-by-one via a single burner drive from an image file on disk onto 16x DVD+R. Even then i experience no undue impact on other processes. I also never noticed a difference when i switched from growisofs to my own programs for that. Is there a realistic scenario where O_DIRECT is reproduciblrye superior to normally buffered reading ? I ponder whether i shall offer a O_DIRECT option with the source objects of libburn. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
mkisofs und input-charset utf-8
Hi Jörg, what does happen if mkisofs is started with -input-charset UTF-8 on a system which is not utf-capable? -- Gruss Marcus Marcus Roeckrath -- Vikarsbusch 8 -- D-48308 Senden -- Germany Phone : +49-2536-9944 -- Fax : +49-2536-9943 E-Mail : [EMAIL PROTECTED] WWW: http://home.foni.net/~marcusroeckrath/ pgpRYDp71JiCj.pgp Description: PGP signature
Contact Mr.Richard Carpenter
You have just been awarded of the sum of £1,200,000.00 GBP in the UK Electronics Award 2008, Anniversary Bonanza. held on December. For Claims:([EMAIL PROTECTED]) Names: Address:.. Country: Phone No:... Occupation:.. Age:.. Sex:.. Regards Mr.Richard Carpenter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs und input-charset utf-8
Marcus Roeckrath [EMAIL PROTECTED] wrote: what does happen if mkisofs is started with -input-charset UTF-8 on a system which is not utf-capable? Why would you do ths is the local filesystem does not use UTF-8 file names? Its the webcdwriter autodetecting correctly that mkisofs on eisfair is not utf-8 capable [webcdwriter log] 163515 T08894 L5 useUTF8 false How could it autodetect this? but allways adds -input-charset UTF-8 to the mkisofs commandline. I had not established a problem with this until now. This can only happen if there is no problem with UTF-8 mkisofs -input-charset BLA -o /dev/null . Unknown charset Known charsets are: iso8859-1 cp1 cp10006 cp10007 cp10029 ... iso8859-7 iso8859-8 iso8859-9 koi8-r koi8-u mkisofs: 'iconv -l' lists more available names. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- 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
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. As you might have imagined timeout value is expressed in seconds, which is why you have to wait 5 minutes. 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. I does mean that it 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. 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. For my reference could you submit first line of 'dvd+rw-mediainfo /dev/scd0' output? It contains INQUIRY result. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Growisofs input cache (get away from dd?)
not passing multiple GB of once-used data through the system buffers and blowing everything else out. I see some effects which could make the O_DIRECT approach less superior to normal reading than your scenario would let expect: O_DIRECT is not about superior performance, it's more about *maintaining adequate _overall_ performance* in wider range of practical situations, most notably under low memory conditions. - If the (ISO) image is freshly generated then the formatter program just blew out everything else anyway. Not if it used O_DIRECT too:-) And for the ISO formatter it makes few sense to read O_DIRECT as it has a random access pattern on eventually small files. It's not about size of individual files, but *sum* of their sizes. Also, if you generate image file (as opposite to immediately burning it out), you double the pressure on block cache as kernel would like to cache both files you've read and recently generated portion of the image. - The cache area in RAM is nowadays quite large and i understand that the least recently used cache chunks get thrown out. While a growisofs read chunk is ageing in the cache for several seconds, any busy process can refresh its own chunks' read time. So i expect that the cache of growisofs' input stream can only blow out chunks which are as fewly used as its own chunks. Right. And if you wanted to record same image again you'd have to start pulling data from disk *anyway*. So why put any pressure on block cache? Why even create the situation when not-busy-enough processes would have to fight for their memory when it can be avoided altogether? Note that [not-so-]busy process would have as many meanings are there are users. I have one use case, though, where i burn two identical copies of the same DVD image for redundancy reasons. One-by-one via a single burner drive from an image file on disk onto 16x DVD+R. Even then i experience no undue impact on other processes. I also never noticed a difference when i switched from growisofs to my own programs for that. Meaning that O_DIRECT is not worse (modulo specific and rare situations like one in originating report), so why the fear?-) Is there a realistic scenario where O_DIRECT is reproduciblrye superior to normally buffered reading ? As implied low memory condition on interactively used system. It's commonly hard for developers to reproduce [and sometimes even understand the problem], as they tend to end up with systems sized above average. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Contact Mr John Carrick.
The sum of £1,000,000,00 GBP Pounds has won by your E-MAIL Do get back to this office with your information via ([EMAIL PROTECTED]) Names : Address: Conntry : Occupation : Age : Sex : Phone : -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
