From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830 Description of problem: The symptom was that xcdroast would 'hang' the system at the point that a burned CD was undergoing fixation. By 'hang', I mean that the X desktop would be responsive for only 1 second in 15-second intervals (1 second of responsiveness, 15 seconds of frozen, another second of responsiveness, 15 more seconds frozen, etc). The xcdroast GUI would just sit there at the 'fixating' step; selecting cancel would eventually bring up the "are you sure" dialog, but nothing I selected would kill xcdroast or allow the system to recover. /var/log/messages would fill up with the following: Feb 11 18:28:25 crypto kernel: hdd: status timeout: status=0xd0 { Busy } Feb 11 18:28:25 crypto kernel: ide-scsi: Strange, packet command initiated yet DRQ isn't asserted Feb 11 18:28:30 crypto kernel: hdd: status timeout: status=0xd0 { Busy } Feb 11 18:28:30 crypto kernel: ide-scsi: Strange, packet command initiated yet DRQ isn't asserted Feb 11 18:28:30 crypto kernel: scsi : aborting command due to timeout : pid 114428, scsi2, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 Feb 11 18:28:30 crypto kernel: SCSI host 2 abort (pid 114428) timed out - resetting Feb 11 18:28:30 crypto kernel: SCSI bus is being reset for host 2 channel 0. Feb 11 18:28:31 crypto kernel: hdd: ATAPI reset complete This set of messages would repeat indefinitely until I got the system to shutdown (an agonizingly slow process). Upgrading to the latest redhat kernel (Linux crypto.home.net 2.4.18-24.8.0smp #1 SMP Fri Jan 31 06:03:47 EST 2003 i686 i686 i386 GNU/Linux) still caused the same behavior. Fortunately, I hit upon the problem (I think). I was putting my name in the "Copyright Information:" field on the "Create CD/ Master Tracks/ISO9660 header" tab, when that field is looking for a filename. When I cleared that field and re-ran my burn, no more problems. OK, sure, I wasn't using xcdroast properly, but ... surely it should handle this error a little more gracefully. It would be wise to test the other fields on this tab that demand a filename and see if they also undergo this same failure. As a matter of fact, if xcdroast is going to be redhat's flagship CD burning application (after all, it is the one installed in the menus for 'System Tools/CD Writer'), maybe you should revisit the QA plan for xcdroast. You might want to expand the testing to include bad data in all the many fields in the xcdroast GUI -- missing files, spaces in filenames, etc. I am marking this bug as 'High' severity because to many people it will appear that the only resolution is to reset or power-off, and that is effectively the same thing as a crash. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.start xcdroast 2.master a CD 3.put a name in the "Copyright Information:" field that does not correspond to a file ("Bruce Wayne") 4.perform burn 5.observe system fubar when fixation occurs Actual Results: system becomes very unresponsive; /var/log/messages gets busy Expected Results: error dialog popup before burn begins: Can't find file "Bruce Wayne" Additional info: uname -a: Linux crypto.home.net 2.4.18-24.8.0smp #1 SMP Fri Jan 31 06:03:47 EST 2003 i686 i686 i386 GNU/Linux cat /proc/cmdline: ro root=LABEL=/ hdd=ide-scsi apm=power-off cat /proc/scsi/scsi: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: SanDisk Model: SDDR33USB/SDMMC Rev: 1.09 Type: Direct-Access ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: SM Media Model: -Shuttle Rev: Type: Direct-Access ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 00 Lun: 00 Vendor: PHILIPS Model: CDRW2412A Rev: P1.5 Type: CD-ROM ANSI SCSI revision: 02 hdparm /dev/hdd: /dev/hdd: HDIO_GET_MULTCOUNT failed: Input/output error IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 0 (off) keepsettings = 0 (off) readonly = 0 (off) BLKRAGET failed: Input/output error HDIO_GETGEO failed: Invalid argument rpm -qi xcdroast: Name : xcdroast Relocations: (not relocateable) Version : 0.98a9 Vendor: Red Hat, Inc. Release : 18 Build Date: Tue 13 Aug 2002 10:33:28 PM CDT Install date: Mon 13 Jan 2003 05:29:42 PM CST Build Host: daffy.perf.redhat.com Group : Applications/Multimedia Source RPM: xcdroast-0.98a9-18.src.rpm Size : 1620650 License: GPL Signature : DSA/SHA1, Tue 03 Sep 2002 04:43:45 PM CDT, Key ID 219180cddb42a60ePackager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.xcdroast.org/ Summary : An X Window System based tool for creating CDs. Description : X-CD-Roast provides a GUI interface for commands like cdrecord and mkisofs. X-CD-Roast includes a self-explanatory X11 user interface, automatic SCSI and IDE hardware setup, support for mastering of new ISO9660 data CDs, support for production of new audio CDs, fast copying of CDs without hard disk buffering, and a logfile option. rpm -qi cdrecord: Name : cdrecord Relocations: (not relocateable) Version : 1.10 Vendor: Red Hat, Inc. Release : 14 Build Date: Sun 23 Jun 2002 09:32:00 AM CDT Install date: Mon 13 Jan 2003 05:21:05 PM CST Build Host: astest.test.redhat.com Group : Applications/Archiving Source RPM: cdrtools-1.10-14.src.rpmSize : 968765 License: GPL Signature : DSA/SHA1, Tue 03 Sep 2002 04:11:08 PM CDT, Key ID 219180cddb42a60ePackager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html Summary : A command line CD recording program. Description : Cdrecord is an application for recording audio and data CDs. Cdrecord works with many different brands of CD recorders, fully supports multi-sessions, and provides human-readable error messages.
isn't this more of a kernel issue?
Yes, this is certainly a kernel issue, especially now that I have had time to do more testing. I have determined that this is not an X-CD-Roast issue, as I have been able to reproduce the problem using gcombust. Sorry for the wild goose chase. The problem is largely as I described it above, but I can pin it down a little more now: intermittently, the CD burning operation will 'hang' at the fixation step. This seems only to occur when I am burning an image to a CD, such as an X-CD-Roast '.img' file, or a '.iso' file. Even then, it will sometimes work fine two or three times in a row, before hanging with the symptoms I described above. In addition to the /var/log/messages output I reported above, I will also see an occasional instance of the following in /var/log/messages: Feb 22 17:25:24 crypto kernel: wait_on_irq, CPU 1: Feb 22 17:25:24 crypto kernel: irq: 0 [ 0 0 ] Feb 22 17:25:24 crypto kernel: bh: 1 [ 1 0 ] Feb 22 17:25:24 crypto kernel: Stack dumps: Feb 22 17:25:24 crypto kernel: CPU 0: <unknown> Feb 22 17:25:24 crypto kernel: CPU 1:c23a9f28 00000001 00000001 ffffffff 00000001 c010bba8 c0273673 00000001 Feb 22 17:25:24 crypto kernel: da069000 c010ad52 00000001 c033ade4 c018d241 dbb1e480 dffc2000 dffc3fc8 Feb 22 17:25:24 crypto kernel: c011d0e4 da069368 c033ade4 c23a9f88 00000000 c23a8000 c0126c4a da069000 Feb 22 17:25:24 crypto kernel: Call Trace: [<c010bba8>] wait_on_irq [kernel] 0xf8 (0xc23a9f3c)) Feb 22 17:25:24 crypto kernel: [<c010ad52>] __global_cli [kernel] 0x62 (0xc23a9f4c)) Feb 22 17:25:24 crypto kernel: [<c018d241>] flush_to_ldisc [kernel] 0xb1 (0xc23a9f58)) Feb 22 17:25:24 crypto kernel: [<c011d0e4>] schedule [kernel] 0x184 (0xc23a9f68)) Feb 22 17:25:24 crypto kernel: [<c0126c4a>] __run_task_queue [kernel] 0x6a (0xc23a9f80)) Feb 22 17:25:24 crypto kernel: [<c0130a67>] context_thread [kernel] 0x147 (0xc23a9f98)) Feb 22 17:25:24 crypto kernel: [<c0130920>] context_thread [kernel] 0x0 (0xc23a9fc8)) Feb 22 17:25:24 crypto kernel: [<c0105000>] stext [kernel] 0x0 (0xc23a9fe8)) Feb 22 17:25:24 crypto kernel: [<c010760e>] kernel_thread [kernel] 0x2e (0xc23a9ff0)) Feb 22 17:25:24 crypto kernel: [<c0130920>] context_thread [kernel] 0x0 (0xc23a9ff8)) I have tried various combinations of hdparm settings and I have also booted with a uniprocessor kernel, and I can always eventually reproduce the problem. So, I don't know what the root problem is, it seems to be some kernel/cdrecord/ide-scsi issue. I don't know how you would go about fixing something like this, I imagine that I will just have to wait for 8.1 and see how things are with a newer kernel. Having to reboot every time I burn an ISO image is more than a little annoying, however. You might want to change the summary of this bug. Please let me know if there is some simple test I can perform to help you resolve the issue. Thanks -
can you try to remove magicdev? (rpm -e magicdev)
OK ... I uninstalled magicdev as directed and rebooted. I don't know that we have definitively determined the problem, but I was able to burn 6 successive CD images without a failure. I didn't know about magicdev, so I poked around in bugzilla ... it certainly looks like it could be the culprit based on what I was able to read. If it is the problem, it is interesting that I am the only one reporting it; I would expect the problem to be a little more widespread. Maybe my hardware configuration increases the exposure to the underlying problem. Was there something in the stack trace that suggested magicdev to you? Or was it just magicdev's "shady reputation" that made you consider it? In any case, if I have to choose between magicdev and CD burning stability, I will live without magicdev. :^] If you can suggest a more definitive test, I might be able to make some time for it. Although my CD spindle is starting to get a little low ... Thanks
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/