For me, and a few of my friends, FC3 has two different kinds of problems regarding CDs:
1/ it no longer burns CDs correctly. ie. they are un-usable. 2/ you can't use dd or md5sum to accurately read or check CDs.
I used the following commands to erase/record (as Xcdroast invoked them)...
cdrecord dev= /dev/cdrom gracetime=2 -v -eject speed=4 blank=fast
cdrecord dev= /dev/cdrom gracetime=2 fs=4096k driveropts=burnfree -v -useinfo speed=4 -dao -eject -pad -data /root/KNOPPIX_V3.7-2004-12-08-EN.iso
==================================================
Here is a summary of my investigations:
- I boot with the older kernel (2.6.9-1.677) and I can burn a CD and read it with dd and I get the correct MD5 - Burning with the later kernel, and the CD's are bad. - 2.6.8.-1.681_FC3 causes problems
read with (exact sector count)
2.6.9-1.677 2.6.8.-1.681_FC3 burned with =========== ================ =========== 2.6.9-1.677 OK OK 2.6.8.-1.681_FC3 bad bad
using a 2.6.9-1.677 burn... read with (no sector count)
2.6.9-1.677 2.6.8.-1.681_FC3 =========== ================ sectors read: 326441 326441
It should have read 326426 2Kbyte sectors)
==================================================
Does anyone care to comment?
Arjan van de Ven wrote:
On Fri, 2004-12-24 at 09:45 -0500, Fulko Hew wrote:
For me, and a few of my friends, FC3 has two different kinds of problems regarding CDs:
question; what kind of device is /dev/cdrom?
In my case /dev/cdrom is a CD/CD-R/DVD combo device ATA-attached as /dev/hdc.
When I first installed FC3, XcdRoast showed it as 3 devices, but now as I check (after all updates to-date) it only shows as '/dev/cdrom' whick is linked to /dev/hdc
(I hope you're not using ide-scsi...
other than the above, I don't know if its using ide-scsi. I thought ide-scsi didn't exist anymore?
On Fri, Dec 24, 2004 at 03:50:44PM +0100, Arjan van de Ven wrote:
On Fri, 2004-12-24 at 09:45 -0500, Fulko Hew wrote:
For me, and a few of my friends, FC3 has two different kinds of problems regarding CDs:
question; what kind of device is /dev/cdrom? (I hope you're not using ide-scsi...
Unlikely - if he was using ide-scsi it would probably work. If it is ide-cd then it suprises me but I can just about see how such behaviour can occur
Alan Cox wrote:
On Fri, Dec 24, 2004 at 03:50:44PM +0100, Arjan van de Ven wrote:
On Fri, 2004-12-24 at 09:45 -0500, Fulko Hew wrote:
For me, and a few of my friends, FC3 has two different kinds of problems regarding CDs:
question; what kind of device is /dev/cdrom? (I hope you're not using ide-scsi...
Unlikely - if he was using ide-scsi it would probably work. If it is ide-cd then it suprises me but I can just about see how such behaviour can occur
Thanks, but your comment doesn't suggest what I should do or try next ;-(
In the mean time I/we have to stick with a pre 2.6.9 kernel on FC2. :-(
On Fri, Dec 24, 2004 at 12:20:05PM -0500, Fulko Hew wrote:
Thanks, but your comment doesn't suggest what I should do or try next ;-( In the mean time I/we have to stick with a pre 2.6.9 kernel on FC2. :-(
What would be useful is to file a bug, and include in it the details of the exact controller/drive/commands used as well as any errors logged in dmesg about the attempt.
Alan
Em Sex, 2004-12-24 às 12:20 -0500, Alan Cox escreveu:
Thanks, but your comment doesn't suggest what I should do or try next ;-( In the mean time I/we have to stick with a pre 2.6.9 kernel on FC2. :-(
What would be useful is to file a bug, and include in it the details of the exact controller/drive/commands used as well as any errors logged in dmesg about the attempt.
I don't know what happens. k3b won't help me understand it. It just says "unknown error 254" and I can no longer record cds. In fact, never could with fc3
On Fri, Dec 24, 2004 at 02:25:23PM -0300, Alexandre Strube wrote:
In the mean time I/we have to stick with a pre 2.6.9 kernel on FC2. :-(
What would be useful is to file a bug, and include in it the details of the exact controller/drive/commands used as well as any errors logged in dmesg about the attempt.
I don't know what happens. k3b won't help me understand it. It just says "unknown error 254" and I can no longer record cds. In fact, never could with fc3
What does cdrecord have to say ?
Alan Cox wrote:
On Fri, Dec 24, 2004 at 02:25:23PM -0300, Alexandre Strube wrote:
In the mean time I/we have to stick with a pre 2.6.9 kernel on FC2. :-(
What would be useful is to file a bug, and include in it the details of the exact controller/drive/commands used as well as any errors logged in dmesg about the attempt.
I don't know what happens. k3b won't help me understand it. It just says "unknown error 254" and I can no longer record cds. In fact, never could with fc3
What does cdrecord have to say ?
Nothing.
I just tried burning a KNOPPIX CD, and cdrecord did not complain or have any unusual messages, however the resultant CD was unusable (read errors), but since I tried booting it I can't read its dmesg.
I'll reboot with an old kernel and try a 'cmp' on the disk and the image. to see where it fails.
Note: I think the result appears to give media read errors, not just bad data. (I hear the CD drive re-seeking.)
Alan Cox wrote:
On Fri, Dec 24, 2004 at 12:20:05PM -0500, Fulko Hew wrote:
Thanks, but your comment doesn't suggest what I should do or try next ;-( In the mean time I/we have to stick with a pre 2.6.9 kernel on FC2. :-(
What would be useful is to file a bug, and include in it the details of the exact controller/drive/commands used as well as any errors logged in dmesg about the attempt.
It has, back on Dec 4 as bugzilla # 141884, but since nothing has really transpired I thought I'd try the mailing list.
This has happened on 3 different hardware/controllers/drives, in two different cities, and there are no dmesg errors.
On Fri, Dec 24, 2004 at 12:26:26PM -0500, Fulko Hew wrote:
It has, back on Dec 4 as bugzilla # 141884, but since nothing has really transpired I thought I'd try the mailing list.
Thanks I'll take a look after Christmas/New year. Internally we've also seen at least one problem drive and are looking into that.
Here is an update to my investigations on why I can no longer burn good CDs on FC2 and FC3. (Bugzilla # 141884)
Background:
With post 2.6.7 kernels, CDs that are burned, cause read errors at semi-random sectors.
Current observations and investigation process:
After reading about people having problems with audio 'hickups' (bugzilla #143421) I was reminded of some 'hickups' I've been hearing lately. Upon further investigation, it turns out that those dropouts were on the original mp3, since they always happened at the same spot.
But that got me to thinking about what happens when I burn CDs...
a) I use a screensaver called "Euphoria" an OpenGL, fairly CPU intensive application. b) Burning CDs takes a while, and my screen saver always kicks in. (because I'm usually doing something else on another machine while waiting.)
So I decide to persue testing on FC3. I won't bore you with all the tests I did over the 25 hours of testing and countless burns. But here are the results (and they uncover another error too).
1/ The timer on the screensaver does not work. - Time values < 20 minutes are obeyed. - Time values >20 minutes always results in a timeout of 20 minutes.
2/ When the screen save kicks in, the CD burn process causes a burn failure.
3/ There is no indication on 'cdrecord' of burn errors. (Burnproof is on, but never used, and min buffer fill was 84%.)
4/ It is independent of actual screen saver selected. (I also tried 'blank screen'.)
5/ The semi-random location of the read error was caused because of the varying screensaving time I had configured, or other keyboard activity that deferred screen timeouts.
6/ Continuous keyboard usage during burning (deferring screen timeouts) results in good burns.
7/ Disabling screen saver results in a good burn (FC3 only, see item 9 below).
8/ It doesn't seem to be related to the 'inform power management about screen blanking' option.
9/ Disabling screen savers on _FC2_ does not work. In addition to observation #1 above, if the screen saver is disabled, the screen will still blank after a maximum of 20 minutes.
Conclusions:
i/ Screen saving timer misbehaves (different symptoms on FC2 versus FC3).
ii/ Screensaving induces CD burn errors.
iii/ A good burn (when read) will read extra data past the sixe of the original ISO written (15 x 2048 bytes)
Note: The original CD error was reported as bugzilla # 141884. I think the original bugzilla should be split into multiple reports. I will do this later today.
On Sun, Jan 16, 2005 at 11:19:44AM -0500, Fulko Hew wrote:
1/ The timer on the screensaver does not work. - Time values < 20 minutes are obeyed. - Time values >20 minutes always results in a timeout of 20 minutes.
Do you have a BIOS set 20 minute display timeout floating around too by any chance ?
iii/ A good burn (when read) will read extra data past the sixe of the original ISO written (15 x 2048 bytes)
Thats correct behaviour. The end of a CD is very low accuracy only.
Alan
Alan Cox wrote:
On Sun, Jan 16, 2005 at 11:19:44AM -0500, Fulko Hew wrote:
1/ The timer on the screensaver does not work.
- Time values < 20 minutes are obeyed.
- Time values >20 minutes always results in a timeout of 20 minutes.
Do you have a BIOS set 20 minute display timeout floating around too by any chance ?
My BIOS has no 'apparent' options. Actually it has very few options. :-(
iii/ A good burn (when read) will read extra data past the sixe of the original ISO written (15 x 2048 bytes)
Thats correct behaviour. The end of a CD is very low accuracy only.
OK. But (in my nievity) doesn't that make it difficult to 'dup' CDs?
ie. you couldn't do a: dd if=/dev/cdrom of=test.iso bs=2048
Fulko Hew adds to his own post:
Alan Cox wrote:
On Sun, Jan 16, 2005 at 11:19:44AM -0500, Fulko Hew wrote:
1/ The timer on the screensaver does not work.
- Time values < 20 minutes are obeyed.
- Time values >20 minutes always results in a timeout of 20 minutes.
Do you have a BIOS set 20 minute display timeout floating around too by any chance ?
My BIOS has no 'apparent' options. Actually it has very few options. :-(
And remember, this CD burn problem _is_ kernel specific. I will do tests later today with older kernels and this 20 minute timeout issue and report back.
iii/ A good burn (when read) will read extra data past the sixe of the original ISO written (15 x 2048 bytes)
Thats correct behaviour. The end of a CD is very low accuracy only.
OK. But (in my nievity) doesn't that make it difficult to 'dup' CDs?
ie. you couldn't do a: dd if=/dev/cdrom of=test.iso bs=2048
On Sun, Jan 16, 2005 at 11:54:25AM -0500, Fulko Hew wrote:
And remember, this CD burn problem _is_ kernel specific. I will do tests later today with older kernels and this 20 minute timeout issue and report back.
Yes. My guess at the moment is something involving acpi or the cpu frequency daemon (acpi=off being one test to do). The reason for this is that when the CPU changes speed it has to disconnect from the system busses and reconnect. Thats a complex process and there are chip errata (and also maybe software bugs of course) in this area which might foul up a current DMA transfer.
Alan
On Sun, Jan 16, 2005 at 11:51:13AM -0500, Fulko Hew wrote:
Thats correct behaviour. The end of a CD is very low accuracy only.
OK. But (in my nievity) doesn't that make it difficult to 'dup' CDs? ie. you couldn't do a: dd if=/dev/cdrom of=test.iso bs=2048
Each copy will gradually get a bit longer unless you know the real .iso size (which is easy to find). The iso file system knows its own size so it ignores the padding
On Sun, 2005-01-16 at 11:54 -0500, Alan Cox wrote:
On Sun, Jan 16, 2005 at 11:51:13AM -0500, Fulko Hew wrote:
Thats correct behaviour. The end of a CD is very low accuracy only.
OK. But (in my nievity) doesn't that make it difficult to 'dup' CDs? ie. you couldn't do a: dd if=/dev/cdrom of=test.iso bs=2048
Each copy will gradually get a bit longer unless you know the real .iso size (which is easy to find).
FWIW, we ship the program "isosize" to do this. So use -pad with cdrecord while burning, and then you can do this to make an iso from it:
dd if=/dev/cdrom of=test.iso bs=4096 \ count=$(($(isosize /dev/cdrom)/ 4096+1))
And that shouldn't have the growth problem Alan has mentioned. Note that the "+1" is only really needed if the image doesn't end on a block boundary.
On Wed, 2005-01-19 at 11:43 -0500, Peter Jones wrote:
On Sun, 2005-01-16 at 11:54 -0500, Alan Cox wrote:
On Sun, Jan 16, 2005 at 11:51:13AM -0500, Fulko Hew wrote:
Thats correct behaviour. The end of a CD is very low accuracy only.
OK. But (in my nievity) doesn't that make it difficult to 'dup' CDs? ie. you couldn't do a: dd if=/dev/cdrom of=test.iso bs=2048
Each copy will gradually get a bit longer unless you know the real .iso size (which is easy to find).
FWIW, we ship the program "isosize" to do this. So use -pad with cdrecord while burning, and then you can do this to make an iso from it:
dd if=/dev/cdrom of=test.iso bs=4096 \ count=$(($(isosize /dev/cdrom)/ 4096+1))
And that shouldn't have the growth problem Alan has mentioned. Note that the "+1" is only really needed if the image doesn't end on a block boundary.
Of course, also note that I'm completely on crack about the block size, and you should just do:
dd if=/dev/cdrom of=test.iso bs=2048 count=$(($(isosize /dev/cdrom)/2048))
as 2048 is the block size on a CD device.
Dunno what I was thinking.
On 01/16/2005 08:19:44 AM, Fulko Hew wrote:
a) I use a screensaver called "Euphoria" an OpenGL, fairly CPU intensive application.
Not sure what Euphoria is part of - but yeah, I always disable screenaver when burning, or what doing something very cpu heavy and long (ie transcoding video)
It has just become habit for me -
xscreensaver-command -exit cdrecord options file
Fulko Hew wrote:
Alan Cox wrote:
What would be useful is to file a bug, and include in it the details of the exact controller/drive/commands used as well as any errors logged in dmesg about the attempt.
I've updated the Bugzilla entry with hardware info.
It has, back on Dec 4 as bugzilla # 141884, but since nothing has really transpired I thought I'd try the mailing list.
I've updated the Bugzilla entry with the results of testing with the new 2.6.9-1.11_FC2 kernel... I still can't burn CDs with it, and it still can't correctly read good CDs either.
This has happened on 3 different hardware/controllers/drives, in two different cities, and there are no dmesg errors.
I stand corrected... when reading good CDs you do get errors logged
"Buffer I/O error on device hdc, logical block 2240"
-
Alan Cox -
Alexandre Strube -
Arjan van de Ven -
Fulko Hew -
Michael A. Peters -
Peter Jones