Bug 141884
| Summary: | writes a shortened image | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Glenn Simpson <gsimpson> |
| Component: | kernel | Assignee: | Alan Cox <alan> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5 | CC: | davej, fulko.hew, tmraz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-10-18 21:24:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Glenn Simpson
2004-12-04 18:05:30 UTC
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. 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 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. 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
> 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.
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. 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. 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. 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. 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. This bug is still occuring in kernel 2.6.15-11.1895_FC5 with the same results that I reported above for disc1, etc 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 The new fc5 kernel should allow you to use ide-scsi instead of ide-cd. This fixes this long standing problem. [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. 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. 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. |