8:45 a.m.
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?
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
9:03 a.m.
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?
11:14 a.m.
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
11:20 a.m.
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. :-(
11:20 a.m.
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
11:25 a.m.
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
11:26 a.m.
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 ?
12:09 p.m.
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.)
11:26 a.m.
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.
11:26 a.m.
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.
10:19 a.m.
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.
10:43 a.m.
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
10:51 a.m.
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
10:54 a.m.
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
10:56 a.m.
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
10:54 a.m.
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
10:43 a.m.
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.
--
Peter
10:46 a.m.
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.
--
Peter
10:58 a.m.
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
7:24 p.m.
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"
7030
days inactive
7056
days old
20 comments
6 participants
participants (6)
-
Alan Cox -
Alexandre Strube -
Arjan van de Ven -
Fulko Hew -
Michael A. Peters -
Peter Jones