Bug 141884 - writes a shortened image
writes a shortened image
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Alan Cox
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-04 13:05 EST by Glenn Simpson
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-18 17:24:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Glenn Simpson 2004-12-04 13:05:30 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040922

Description of problem:
When writing disc2 of the FC3 released CDs for the i386, and using the
FC3 on either an AMD 2000+ OR a AMD64 3500+, the ISO is written
shorter than the supplied image.  My experience is 77,824 bytes short.
 Consistently.

Version-Release number of selected component (if applicable):
current FC3 release on 2.6.9 kernel

How reproducible:
Always

Steps to Reproduce:
1.using a valid copy of FC3-disc2.iso
2.use cdrecord -v -tao FC3-disc2.iso  (or what ever file you are using)
3.now remove the newly written CD.  (I was using an 80 Min, write once)
4.us 'dd' to extract the image from the CD
  dd if=/dev/hdc of=disc2.iso bs=2K count=326426
  where bs is the sector size.  count is the number of sectors.
  calc file size in bytes divided by sector size
5.if you get a disc io error, it indicates the disc was short of
  the valid number of sectors.
  if you don't get an io error, use md5sum on the resulting image
  to determine if you have a valid image.

Actual Results:  the dd request will end with the number of sectors
read less than the specified count.  I get 326388 block read instead
of 326426.
This will result in an invalid md5 due to the difference in file size.

Expected Results:  When specifying 326426 blocks, I expect NO io error
from dd.
When I run md5sum on the resulting image, I expect a valid value.

Additional info:

Note, this bug is data dependent.  I seem to get disc1 of the FC3
distro correct, but I fail disc2, 3 and 4.  I have focused on disc2,
because I have consistent results on a number of hosts, using
different burners.

My burner is an hp9500.  Other hosts have none hp burners.
My burner is pure CD.  Other burners also support DVD, etc.
Comment 1 Fulko Hew 2004-12-05 23:06:03 EST
I've been having the same issue and after tests I believe that the new
kernel  2.6.8-1.681_FC3 has a problem writting CDs.

I performed a test with both the old kernel (2.6.9-1.677) and the new
kernel mentioned above.  Any burn made with the new kernel could not
be read, by either kernel.  Burns made with the old kernel could be
read with the new kernel.

In addition... I used to use dd to read the CD for verification and it
always returns an icorrect number of sectors.

(During my tests I burned the ISO for FC3 disk2)

1/ burning with kernel 2.6.9-1.681_FC3, created a CD that could not
successfully be read on either kernel.

2/ burning with kernel 2.6.9-1.677 creates a CD that could be read on
both the old kernel and the new kernel.

3/ Using a 'good' CD burned with the old kernel and using the 'dd'
command.  
  dd if=/dev/hdc of=t.f bs=2048

always returns 326441 sectors read (whereas the number should have
been 326426 sectors.

4/ using the dd approach on a 'bad' cd burned with the new kernel
causes dd to stop after a psuedo random number of sectors (I've had it
stop after 2932 and 6068 sectors.)


Conclusion:

Only the old kernel can successfully create CDs.
Comment 2 Fulko Hew 2005-01-03 19:24:03 EST
a) Re-tested with the new FC2 kernel released today, 2.6.9-1.11_FC2.

 It still cannot burn good CDs.  There are no apparent errors on
cdrecord, and when read with 'dd', dd reports:

  [root@localhost root]# dd if=/dev/cdrom of=t.f bs=4k
  dd: reading `/dev/cdrom': Input/output error
  1658+0 records in
  1658+0 records out
  [root@localhost root]#

  /var/log/messages reports:

  Jan  3 18:54:22 localhost kernel: Buffer I/O error on device hdc,
logical block 3340

  It also reports the same error on each logical block between 2240
through 3379.

b) When reading good CDs, burnt with older kernels, the new kernel
reads extra data ( 178948 blocks (4K block size ) versus the expected
178941 records) (this test was performed trying to burn the 
KNOPPIX_V3.7-2004-12-08-EN.iso)

Note: On  FC2 the following kernels also create 'bad' CDs:
  2.6.9-1.6_FC2
  2.6.9-1.3_FC2
The last known 'good' kernel that can create 'good' CDs was:
  2.6.8-1.521


Comment 3 Fulko Hew 2005-01-03 20:23:25 EST
As per Alan Cox's request for hardware descriptions of the test
platforms, there are different platforms that we are using for testing:

1/ Asus A7N8XE-delux motherboard, AMD XP2000+ CPU, HP 9500CD writer
2/ P3 Coppermine 6 CPU (unknown motherboard) 
3/ Centrino based laptop (Compal BCL-50)

All systems have the 'read' problem.

System #3 has the 'burn' problem.
Comment 4 Fulko Hew 2005-01-04 23:33:41 EST
Re-tested with kernel 2.6.9-1.724_FC3 and the same 'cannot
successfully burn' problem still exists.  On the Centrino laptop
described above, I used the command:

  cdrecord -v -tao -blank=fast KNOPPIX_V3.7-2004-12-08-EN.iso

During the burn process, cdrecord logged no errors and neither did
/var/log/messages.

I then performed the 'dd' command to read the CD and got:

 [root@localhost ~]# dd if=/dev/cdrom of=t.f bs=4096
 dd: reading `/dev/cdrom': Input/output error
 1274+0 records in
 1274+0 records out

The /var/log/messages file reported:

Jan  4 23:21:24 localhost kernel: hdc: media error (bad sector):
status=0x51 { DriveReady SeekComplete Error }
Jan  4 23:21:24 localhost kernel: hdc: media error (bad sector):
error=0x30
Jan  4 23:21:24 localhost kernel: ide: failed opcode was 100
Jan  4 23:21:24 localhost kernel: ATAPI device hdc:
Jan  4 23:21:24 localhost kernel:   Error: Medium error -- (Sense
key=0x03)
Jan  4 23:21:24 localhost kernel:   Unrecovered read error --
(asc=0x11, ascq=0x00)
Jan  4 23:21:24 localhost kernel:   The failed "Read 10" packet
command was:
Jan  4 23:21:24 localhost kernel:   "28 00 00 00 09 f4 00 00 40 00 00
00 00 00 00 00 "
Jan  4 23:21:24 localhost kernel: end_request: I/O error, dev hdc,
sector 10192
Jan  4 23:21:24 localhost kernel: Buffer I/O error on device hdc,
logical block 1274

  ...

Jan  4 23:21:24 localhost kernel: Buffer I/O error on device hdc,
logical block 1305
Comment 5 John Degenstein 2005-01-07 22:54:38 EST
> kernel: hdc: media error (bad sector): status=0x51 { DriveReady
SeekComplete Error }

I also used to have problems similar to what you are experiencing, my
resolution was to compile a custom kernel with support for ide-scsi. 
I would like to known why ide-cd seems to be so flawed and always
fails when I try and burn a CD from within FC3, the problem seemed to
get worse with time until I could no longer even access the drive at all.
Comment 6 Dave Jones 2005-07-15 14:37:16 EDT
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.
Comment 7 Glenn Simpson 2005-07-16 11:49:46 EDT
using FC4.disc2.iso as the test image, when I use cdrecord with kernel
2.6.12-1.1372_FC3 I still get a short read when I use dd to read back the image
from the CD-RW.

If I boot FC3 with 'nodma', I still get a short image, but this time it is only
6 sectors short.

If I use FC5 development (kernel 2.6.12-1.1400, I get a correct image for the
same iso test, with normal 'dma', I get the correct size image.

I do not have an FC4 released distro so I can not report on FC4.
Comment 8 Dave Jones 2006-01-16 17:12:51 EST
This is a mass-update to all currently open Fedora Core 3 kernel bugs.

Fedora Core 3 support has transitioned to the Fedora Legacy project.
Due to the limited resources of this project, typically only
updates for new security issues are released.

As this bug isn't security related, it has been migrated to a
Fedora Core 4 bug.  Please upgrade to this newer release, and
test if this bug is still present there.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

Thank you.
Comment 9 Glenn Simpson 2006-01-17 10:06:59 EST
Using FC5 T1, the write short still occurs.
I used the cmd
   cdrecord -v -tao xxxxx.iso
where xxxxx.iso is the iso file to be written
I read the CD back with
   dd if=/dev/hdc of=discX.iso bs=2K
where 'X' is the disc number
and got the following results

Disc    blocks written  blocks read by 'dd'
disc1    315626          315568
disc2    320316          320304
disc3    324711          324656
disc4    326171          326128
disc5    202889          202864

I have seen info elsewhere that suggests this problem may be DMA related.
Comment 10 Dave Jones 2006-02-03 00:54:22 EST
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.
Comment 11 Glenn Simpson 2006-02-03 12:21:34 EST
This bug is still occuring in kernel 2.6.15-11.1895_FC5 with the same results
that I reported above for disc1, etc
Comment 12 Glenn Simpson 2006-02-05 13:20:52 EST
the write short appears to be DMA associated.

If you disable DMA and repeat the test, you will read the correct number of
blocks.  Example:
   hdparm -d0 /dev/hdc     # where I assume the drive is /dev/hdc

   dd -if=/dev/hdc of=disc.iso bs=2K

You should read the number of block back that were written from the original ISO
file.

I have tried this on the following type hosts
   P3 based with an LG 52X cd reader
   AMD 2000+ based with an HP 9500 cdwriter
Comment 13 Alan Cox 2006-05-15 12:50:21 EDT
The new fc5 kernel should allow you to use ide-scsi instead of ide-cd. This
fixes this long standing problem. 
Comment 14 Dave Jones 2006-09-16 22:51:19 EDT
[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.
Comment 15 Dave Jones 2006-10-16 15:02:33 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 16 Glenn Simpson 2006-10-18 17:23:25 EDT
The problem reported by this bug can be avoided by use mode SAO.

Thus used the cmd
   cdrecord -v -sao xxxxxx
where xxxxxx is the iso file you wish to write.

Note You need to log in before you can comment on or make changes to this bug.