Bug 84098 - (IDE IDE-SCSI)xcdroast kills system if copyright information file doesn't exist
(IDE IDE-SCSI)xcdroast kills system if copyright information file doesn't exist
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-11 23:23 EST by Need Real Name
Modified: 2007-04-18 12:51 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:40:31 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 Need Real Name 2003-02-11 23:23:26 EST
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.
Comment 1 Harald Hoyer 2003-02-17 06:29:22 EST
isn't this more of a kernel issue?
Comment 2 Need Real Name 2003-02-24 14:02:19 EST
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 -
Comment 3 Arjan van de Ven 2003-02-24 14:14:39 EST
can you try to remove magicdev? (rpm -e magicdev)
Comment 4 Need Real Name 2003-02-28 15:12:39 EST
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
Comment 5 Bugzilla owner 2004-09-30 11:40:31 EDT
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/

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