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".