Bug 84098
Summary: | (IDE IDE-SCSI)xcdroast kills system if copyright information file doesn't exist | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <comcast.really.sucks> |
Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-09-30 15:40:31 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
Need Real Name
2003-02-12 04:23:26 UTC
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/ |