Bug 99473
Summary: | cdrecord "Fixating" fails with timeout | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Warren Togami <wtogami> |
Component: | kernel | Assignee: | Dave Jones <davej> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | behdad, pfrields |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-02-15 02:42:04 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: | |||
Bug Depends On: | |||
Bug Blocks: | 100643 |
Description
Warren Togami
2003-07-20 23:52:18 UTC
Is this still a problem with latest kernels? Also, without the actual oops, this is unlikely to get fixed as I've been unable to reproduce locally. I will attempt it again later today. http://www.memtest86.com/memtest86-3.0.iso.gz I tested the burning using this tiny ISO file. kernel-2.4.22-1.2115.nptl kernel-2.4.20-20.9 cdrecord-2.01-0.a19.1 cdrecord-2.0-6 These versions of kernels and cdrecord were tested, from FC1 and RH9. It seems that whatever kernel bug was causing panics in earlier Severn kernels has been fixed. Now "Fixating" gets stuck for a very long time. While it is stuck it appears like this: root 4844 4843 0 19:18 tty1 00:00:00 [cdrecord <defunct>] root 4845 4710 0 19:19 tty2 00:00:00 -bash root 4843 4780 0 19:18 tty1 00:00:00 cdrecord -v speed=1 dev=0,0,0 meroot 4908 4845 0 19:20 tty2 00:00:00 ps -ef [root@laptop root]# strace -p 4843 Process 4843 attached - interrupt to quit ioctl(3, 0x2285 <unfinished ...> Process 4843 detached [root@laptop root]# strace -p 4844 attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted Eventually it stops with these errors in dmesg: scsi : aborting command due to timeout : pid 298, scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 scsi : aborting command due to timeout : pid 298, scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 SCSI host 0 abort (pid 298) timed out - resetting SCSI bus is being reset for host 0 channel 0. SCSI host 0 channel 0 reset (pid 298) timed out - trying harder SCSI bus is being reset for host 0 channel 0. Then cdrecord reports: cdrecord: Cannot fixate disk. Fixating time: 204.155s cdrecord: fifo had 27 puts and 27 gets. cdrecord: fifo was 0 times empty and 0 times full, min fill was 100%. This was last working properly in pure RH9, so I tested the latest RH9 errata kernel and RH9 cdrecord. It seems to not solve the problem. Should I try the original RH9 kernel too? Any other ideas? At least the kernel panic no longer happens... I remember fixating working for me on updated RH9, which I burnt test2 ISOs, but it used to get locked (in your last case) with any vanilla 2.6 kernels. BTW, just rebooted the machine and the CD was usable. Tried right now with kernel 2.4.22-1.2115.nptl and cdrecord-2.01-0.a19.2 and worked like a charm. Warren, can give it another try? I'm on a Sony Vaio P4M. I gave this MULTIPLE tries across many reboots. This is a real issue. is DMA enabled on the CD drive? If it is, does disabling it fix it ? Same behavior with DMA enabled or disabled. DMA seems to be enabled by default. Well, I no longer care about this bug as I don't use 2.4 kernels anymore. REOPEN if anyone runs into this again. This still happen. Downgrading to stock mkisofs and cdrecord works. |