Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030121 Description of problem: Since kernel 2.4.20-2.29 it's no longer possible to burn .iso files using cdrecord on my system. On kernel versions 2.4.20-2.21 and 2.4.20-2.25 burning an .iso works without problems. I have the following kernels available on my modified (partially upgraded to latest Rawhide) Phoebe 8.0.93 version : - kernel 2.4.20-2.44 - kernel 2.4.20-2.39 - kernel 2.4.20-2.34 - kernel 2.4.20-2.30 - kernel 2.4.20-2.29 - kernel 2.4.20-2.25 - kernel 2.4.20-2.21 From kernel 2.4.20-2.29 up to kernel 2.4.20-2.44 this problem is easily reproducable. Kernel 2.4.20-2.21 and 2.4.20-2.25 reproducably work without problems Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Download movix .iso from http://movix.sourceforge.net/ 2. "# cdrecord -dev=0,0,0 movix.iso" 3. Actual Results: With Phoebe/Rawhide kernels 2.4.20-2.29 up to 2.4.20-2.44, cdrecord returns an Input/output error to the shell. With Phoebe/Rawhide kernels 2.4.20-2.21 and 2.4.20-2.25 , cdrecord works without problems. Expected Results: All new kernels, which are candidate to be included in the next public beta/final, should work without problems. Additional info: cdrecord-2.0-3 Red Hat Linux release 8.0.93 kernel-2.4.20-2.21 kernel-2.4.20-2.25 kernel-2.4.20-2.29 kernel-2.4.20-2.30 kernel-2.4.20-2.34 kernel-2.4.20-2.39 kernel-2.4.20-2.44 Here's the output of Cdrecord's I/O error : Cdrecord 2.0 (i686-pc-linux-gnu) Copyright (C) 1995-2002 Jrg Schilling scsidev: '0,0,0' scsibus: 0 target: 0 lun: 0 Linux sg driver version: 3.1.24 Using libscg version 'schily-0.7' Device type : Removable CD-ROM Version : 0 Response Format: 2 Capabilities : Vendor_info : 'COMBI ' Identifikation : 'RW16x10/DVD ' Revision : 'N1.1' Device seems to be: Generic mmc2 DVD-ROM. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : MMC-2 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO RAW/R16 RAW/R96R Starting to write CD/DVD at speed 4 in real TAO mode for single session. Last chance to quit, starting real write 0 seconds. Operation starts. Turning BURN-Free off cdrecord: Input/output error. write_g1: scsi sendcmd: no error CDB: 2A 00 00 00 34 AD 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: F0 00 05 00 00 34 AD 13 00 00 00 00 21 00 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x21 Qual 0x00 (logical block address out of range) Fru 0x0 Sense flags: Blk 13485 (valid) cmd finished after 14.950s timeout 40s write track data: error after 27617280 bytes Sense Bytes: 70 00 00 00 00 00 00 13 00 00 00 00 00 00 00 00 00 00
Arjan what changed .21 to .25 - is it by any chance enabling DMA on CD devices. The trace looks like the cd app wrote gaga data to the drive, or of course the not unreasonable alternative is that something in the DMA stuff corrupted the command. Peter - can you attach an lspci -v and info on what drives are attached to which controller ?
I'll attach both the output of "dmesg" and "lspci" to this Bugzilla.
Created attachment 90065 [details] Output of dmesg
Created attachment 90066 [details] Output of lspci -v
Created attachment 90067 [details] Output of lspci -v -v
I'm seeing the same thing, and I just upgraded a standard 8.0 install to 8.0.94. I will attach the same files as Peter has done.
Created attachment 90238 [details] cdrecord/xcdroast output
Created attachment 90239 [details] dmesg output
Created attachment 90240 [details] lspci -v output
Just to be clear, I'm using kernel 2.4.20-2.48
Did a clean install of Phoebe 8.0.94. Now even formatting a CDRW with "cdrecord -v -dev=0,0,0 blank=fast" result in : cdrecord: Input/output error. blank unit: scsi sendcmd: cmd timeout after 22.300 CDB: A1 01 00 00 00 00 00 00 00 00 00 00 This is what "dmesg" says : scsi : aborting command due to timeout : pid 107911, scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 scsi : aborting command due to timeout : pid 107911, scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 SCSI host 0 abort (pid 107911) timed out - resetting SCSI bus is being reset for host 0 channel 0. hdc: DMA disabled hdc: ATAPI reset complete hdc: status error: status=0x7f { DriveReady DeviceFault SeekComplete DataRequest CorrectedError Index Error } hdc: status error: error=0x7f hdc: drive not ready for command hdc: ATAPI reset complete hdc: status error: status=0x7f { DriveReady DeviceFault SeekComplete DataRequest CorrectedError Index Error } hdc: status error: error=0x7f hdc: drive not ready for command hdc: ATAPI reset complete scsi : aborting command due to timeout : pid 107911, scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 SCSI host 0 abort (pid 107911) timed out - resetting SCSI bus is being reset for host 0 channel 0. scsi : aborting command due to timeout : pid 107911, scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 SCSI host 0 abort (pid 107911) timed out - resetting SCSI bus is being reset for host 0 channel 0. hdc: ATAPI reset complete
Created attachment 90278 [details] lspci-v result I wonder if I could just update Phoebe 2 (RH 8.0.9.3) with Phoebe 3 (RH 8.0.9.4), since I can't (read "I'm a newbie/dummy who doesn't know HOWTO) install the older kernel: [root@Knoppix RPMS]# rpm -ivh kernel-2.4.20-2.48.athlon.rpm Preparing... ########################################### [100%] package kernel-2.4.20-2.51 (which is newer than kernel-2.4.20-2.48) is already installed [root@Knoppix RPMS]# rpm -e kernel-2.4.20-2.51.athlon.rpm error: package kernel-2.4.20-2.51.athlon.rpm is not installed NB: Strange ... I *did* install kernel-2.4.20-2.51 (confirmed via /var/log/rpmpkgs) Yet the output shown above gives conflicting information.
Results from additional testing: 1. Problem still exists when using rawhide kernel 2.4.20-2.51.athlon.rpm 2. Physically swapping out CDRWs made little difference. Replaced my plextor 16/10/40A with a cheapo OptoRite 48/16/48 CDRW and was actually able to burn a couple of discs, but one of them was a coaster and the other has potential data corruption. Neither of the discs were made without the same SCSI bus errors as previously noted wrecking the system. One of those crashes forced me to do a cold reset to get it working again. 3. Turning DMA on/off with hdparm -d1/-d0 and with "options ide-cd dma=1" in /etc/modules.conf also made no difference. Plan to stick with the OptoRite CDRW for now since it fixes another bug I was experiencing: inability to hear sound when playing audio CDs through gnome CD player.
*** Bug 84762 has been marked as a duplicate of this bug. ***
Created attachment 90432 [details] output from X-CD-Roast and Gnome Toaster with kernel-2.4.18-14 I have even installed the older kernel from RH 8.0, *removed* magicdev as recommended on the phoebe-beta list, AND added the folowing to my /etc/modules conf file, with no improvement: alias scsi_hostadapter ide-scsi The consistent failure is *repeatable* even using cdrecord-2.0-4 at the command console.
current version levels on my system (Feb. 28): CPU AMD Athlon Thunderbird, using "athlon" versions of: kernel-2.4.18-14 (installed from RH 8.0) kernel-2.4.20-2.48 (default) kernel-2.4.20-2.54 (rawhide) Hardware: physical=/dev/hdc. Mount point=/dev/cdrom1 TEAC CD-W516EB, BIOS recently updated to 1.0J (using MS Windows). Other device:PIONEER DVD 116/2/KBXCN(Secondary slave) physical=/dev/hdd, mount point=dev/dcrom System memory: 512 MB (PC-100)
FWIW, updated my test system to kernel 2.4.20-2.49smp and cdrecord 2.0.4 and still had failures from both CLI invocation of cdrecord and X-cd-roast. Based on advice from another beta tester, removed "magicdev" from system and the problems have gone away (4 test cases 2 w/GUI and 2 /CLI invocation). I can now both blank a CD/RW and burn a "clean" iso to a CDR without the previous hangs. The past problem with burning a CDR seemed to revolve around the "fixating" phase of the process. Could this be a problem with an interaction between polling by magicdev and the driver?
Chiming in with a resounding: Hasn't worked for me in a while either. Alan: DMA used to work quite nicely on my cd & dvd burners (actually a lot better) with previous redhat versions, so it seems unlikely that that would be at the root of this. Maybe cdrecord uses a thread/priority call to try to get the high-priority it needs and the new posix threads are blowing this up? Just a thought
I would like to comment that disc burning has been a problem since the introduction of RH8.0. I am not able to get decent copies of burned CDRs that will work in audio players, my cdrom for my laptop or my cdrom readers at work. I suspect that the earlier conclusion that the readers was at fault was not a valid writeoff. It appears that evaluation of the error messages that are produced by trying to run a media check on these previously written off cdrom readers needs to be re-evaluated, in order to put dependable cdr operation back into the later distributions.
Since magicdev was considered a suspect for causing problems with cd burning. I killed magicdev off and tried to launch xcdroast. xcdroast locked up, tried to burn on my cd reader and eventually displayed an empty error dialog box to the GUI. (GNOME). I launched gtoaster sucessfully and am about 30% done with the burn. The burn speed is set to 2 times. This is to test if RH7.3 actually is better at recording CDs or if magicdev is messing up the CDR recording process. After this burn is completed, I plan on testing the resulting image in my laptop's cd reader. It has not worked properly since RH7.3.
Additional comments for after killing magicdev are that my fstab file is really messed up. Also, cdrom1, cdrom2, cdrom3 were linked to different devices. [bash]$ cat /etc/fstab LABEL=/ / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 /dev/hda1 /7_3boot ext3 noauto,owner 1 3 /dev/hda2 /7_3root ext3 noauto,owner 1 3 /dev/hdb3 /home/jim/stuff ext3 defaults 1 3 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 /dev/hdb5 /swap swap defaults 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 /dev/sda1 /mnt/flash auto noauto,owner,kudzu 0 0 /dev/cdrom1 /mnt/cdrom1 udf,iso9660 noauto,owner,ro 0 0 /dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0 /dev/cdrom2 /mnt/cdrom2 udf,iso9660 noauto,owner,kudzu,ro 0 0 /dev/cdrom3 /mnt/cdrom3 udf,iso9660 noauto,owner,kudzu,ro 0 0 [bash]$ ls -l /dev/cdrom* lrwxrwxrwx 1 root root 9 Mar 1 07:34 /dev/cdrom -> /dev/scd1 lrwxrwxrwx 1 root root 9 Feb 24 13:39 /dev/cdrom1 -> /dev/scd0 lrwxrwxrwx 1 root root 8 Mar 5 17:37 /dev/cdrom2 -> /dev/hdc lrwxrwxrwx 1 root root 8 Mar 5 17:37 /dev/cdrom3 -> /dev/hdd Now to try out the burned disc.
I now seem to have _fairly consistent_ success since appending the following to my /etc/modules.conf file: options ide-cd dma=1 still testing to see if the rectification is now consistent. Kernels: kernel-2.4.20-2.48 (default) kernel-2.4.20-2.54
After rebooting the system about two days ago. The same time period that I burned the CDR in for test purposes. I got the below in my /etc/fstab file. (The elimination of /dev/cdrom linked to /dev/hdc) [bash]$ cat /etc/fstab LABEL=/ / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 /dev/hda1 /7_3boot ext3 noauto,owner 1 3 /dev/hda2 /7_3root ext3 noauto,owner 1 3 /dev/hdb3 /home/jim/stuff ext3 defaults 1 3 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 /dev/hdb5 swap swap defaults 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 /dev/sda1 /mnt/flash auto noauto,owner,kudzu 0 0 /dev/cdrom1 /mnt/cdrom1 udf,iso9660 noauto,owner,ro 0 0 /dev/cdrom3 /mnt/cdrom3 udf,iso9660 noauto,owner,kudzu,ro 0 0 [bash]$ ls -l /dev/cdrom* lrwxrwxrwx 1 root root 9 Feb 24 13:39 /dev/cdrom1 -> /dev/scd0l rwxrwxrwx 1 root root 9 Mar 10 18:26 /dev/cdrom3 -> /dev/scd1 I don't know what is giong on with the interaction. The CDR that I burned on phoebe3 did mediacheck alright. There was however drive seek errors and reset errors that took hold, after the media check completed. This leads me to think that killing magicdev helps to correct the every 5 second drive seek errors and writing outside boundaries. I still don't trust burning after RH 7.3 for purity. Something went wrong in that period. I'll attach my dmesg and lspci outputs shortly.
Created attachment 90578 [details] output of lspci -v This is regarding the changing fstab, 5 second interval erros that are actually burned to the disc, or are reproduced on my cd reader for my laptop.
Created attachment 90579 [details] dmesg - why trying to burn on cd reader This is to figure out why my cdreader was attempted to be written to,by xcdroast, after killing magicdev ( to get rid of 5 second intervals for timeout errors)
Created attachment 90580 [details] This is from the event log of a disc buned in phoebe2 This disc has errors, see attached event log message from my work machine.
After having enabled DMA via /etc/modules.conf, I can only burn data CD's. Audio burns fail constantly. This is with Phoebe 3 /RH 8.0.94, kernel-2.4.20-2.48. Magicdev is NOT installed on the system. Using either MP3 or WAV files, this *consistently* happens: GnomeToaster completes the burn and then my system locks up with the CAPS-LOCK and SCROLL-LOCK LED's on my PS/2 keyboard blinking incessantly. CTRL-ALT-BKSPC does *not* return me control of the system --- I am obliged to hit the _reset_ button my my box.
This question has to do with the rewritten drivers for ide purposes. Is it possible that the rewritten IDE drivers and hdx=ide-scsi are not in step with each other? I am still convinced that testing this problerm on drives that werer previously written off will show better data corruption results. you need to evaluate this problem with no correction byu devices or drivers and compare it with an image burned on the pretty near perfect RH7.3 burned CDs. Of courase most of my other intuitive ideas have been blown over. Good luck! Jim
I recently bought a 52 speed IDE CD-RW drive. Under Red Hat 8.0.94 (stock kernel), I experienced several errors trying to write CDs at 48 or 52 speed, but these disappeared when dropping back to a more conservative speed such as 24 speed (however the drive often had to idle and buffer data using burnfree/burnproof even at 24 speed). As I only recently obtained the drive, I can't comment on previous behavior. I have a DVD-ROM drive on hdc and a CD-RW drive on hdd (/dev/scd0 using IDE-SCSI emulation). I decided to make the DVD-ROM drive use IDE-SCSI as well, and I am now able to burn at 48 speed with no idle periods. I agree it seems likely that the new IDE code (perhaps only when using DMA) has problems when another device on the same IDE channel is using IDE-SCSI, but can't provide any concrete information. I actually like the concept of all CD drives using IDE-SCSI if one CD drive is, anyway, and raised bug 86453 to suggest this.
I will try to add a kernel parameter to recognize both of my devices as simulated generic scsi devices. I noticed that withouth this additional parameter added hdx=ide-scsi fo reader drives. The gtoaster program does not recognize my reader as a cdrom drive. If there was a rewrite for the ide drivers, it would severely interfere with the basic calls to the hdx device, then passed onto the simulated scsi device, which burns with the sgx device, but reads with the scdx device driver. I think that adding udf writing capability, to the ide drivers, will make management of cdroms a bit more powerful. I do think that the ide-scsi driver needs to be updated or found a way to work with cd burners, without resorting to treating them as scsi devices.
This bug seems fixed for me in Red Hat Linux release 9 (Shrike). I did a fresh install of Red Hat Linux 9 on my system and successfully did (both in KDE and GNOME) : - burn a few iso's with cdrecord including the before-mentioned "movix.iso". - erase some CD-RW's with cdrecord. I also successfully burned some files on CD-RW with "nautilus-cd-burner" in GNOME. I'll change the status of this Bugzilla report from "NEW" to "CURRENTRELEASE".