From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2 i686) Description of problem: Kernel hanged in the middle of writing a cd-rw on my Acer 6206a before or after a firmware upgrade (1.2a or 1.6a). Problem can also sometimes be reproduced by removing the CD from the drive while grip is searching for info on the drive. The following shows up repeatedly on /var/log/messages: Jun 9 22:28:40 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:28:40 localhost kernel: scsi : aborting command due to timeout : pid 0 , scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 Jun 9 22:28:40 localhost kernel: SCSI host 0 abort (pid 0) timed out - resettin g How reproducible: Sometimes Steps to Reproduce: 1.run grip 2.play the cd 3.eject the cd 4. exit grip (with cd-drive open) Actual Results: machine hesitates. Becomes increasingly unresponsive. After about 30 seconds stops responding. Will not reply even to the 3-finger salute. Expected Results: kernel should have reported errors, and eventually reset the device, or even crashed the app, but not hanged... Additional info: I have a pretty slow machine, a Cyrix 200 with 80M and 80M swap. I also have a 20G harddrive on the same ide channel as the cd-rw. This is the messages file from right before it hangs. The messages in the first group (SCSI bus is being reset....resetting) are repeated many many times, and every third time, the status is returned as {BUSY}. The "return code=2700002" only shows up that one time. Jun 9 16:59:34 localhost kernel: sr0: CDROM (ioctl) reports ILLEGAL REQUEST. Jun 9 16:59:39 localhost last message repeated 5 times Jun 9 22:27:52 localhost kernel: sr0: CDROM not ready. Make sure there is a di sc in the drive. Jun 9 22:28:17 localhost last message repeated 25 times Jun 9 22:28:29 localhost kernel: scsi : aborting command due to timeout : pid 0 , scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 Jun 9 22:28:39 localhost kernel: scsi : aborting command due to timeout : pid 0 , scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 Jun 9 22:28:39 localhost kernel: SCSI host 0 abort (pid 0) timed out - resettin g Jun 9 22:28:39 localhost kernel: SCSI bus is being reset for host 0 channel 0. ...[EDITED OUT].... Jun 9 22:28:56 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:28:57 localhost kernel: hdc: ATAPI reset complete Jun 9 22:28:57 localhost kernel: hdc: irq timeout: status=0xd0 { Busy } Jun 9 22:28:57 localhost kernel: scsi : aborting command due to timeout : pid 0 , scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 Jun 9 22:28:57 localhost kernel: SCSI host 0 abort (pid 0) timed out - resettin g Jun 9 22:28:57 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:28:58 localhost kernel: scsi : aborting command due to timeout : pid 0 , scsi0, channel 0, id 0, lun 0 Test Unit Ready 00 00 00 00 00 Jun 9 22:28:58 localhost kernel: SCSI host 0 abort (pid 0) timed out - resettin g Jun 9 22:28:58 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:28:58 localhost kernel: hdc: ATAPI reset complete Jun 9 22:29:00 localhost kernel: hdc: irq timeout: status=0xd0 { Busy } Jun 9 22:29:05 localhost kernel: SCSI error: host 0 id 0 lun 0 return code = 27 000002 Jun 9 22:29:05 localhost kernel: ^ISense class 0, sense error 0, extended sense 0 Jun 9 22:29:05 localhost kernel: scsi0 : channel 0 target 0 lun 0 request sense failed, performing reset. Jun 9 22:29:05 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:29:07 localhost kernel: scsi0 : channel 0 target 0 lun 0 request sense failed, performing reset. Jun 9 22:29:07 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:29:09 localhost kernel: scsi0 : channel 0 target 0 lun 0 request sense failed, performing reset. Jun 9 22:29:09 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:29:13 localhost kernel: scsi0 : channel 0 target 0 lun 0 request sense failed, performing reset. Jun 9 22:29:19 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:29:19 localhost kernel: SCSI error: host 0 id 0 lun 0 return code = 18 000002 Jun 9 22:29:19 localhost kernel: ^ISense class 0, sense error 0, extended sense 0 Jun 9 22:29:19 localhost kernel: SCSI error: host 0 id 0 lun 0 return code = 18 000002 Jun 9 22:29:19 localhost kernel: ^ISense class 0, sense error 0, extended sense 0 Jun 9 22:29:19 localhost kernel: scsi0 : channel 0 target 0 lun 0 request sense failed, performing reset. Jun 9 22:29:19 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:29:19 localhost kernel: scsi0 : channel 0 target 0 lun 0 request sense failed, performing reset. Jun 9 22:29:19 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:29:19 localhost kernel: scsi0 : channel 0 target 0 lun 0 request sense failed, performing reset. Jun 9 22:29:19 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:29:19 localhost kernel: SCSI error: host 0 id 0 lun 0 return code = 18 000002 Jun 9 22:29:23 localhost kernel: ^ISense class 0, sense error 0, extended sense 0 Jun 9 22:29:33 localhost kernel: sr0: CDROM (ioctl) error, command: Start/Stop Unit 01 00 00 00 00 Jun 9 22:29:34 localhost kernel: sr00:00: old sense key None Jun 9 22:29:34 localhost kernel: Non-extended sense class 0 code 0x0 Jun 9 22:29:34 localhost kernel: scsi0 : channel 0 target 0 lun 0 request sense failed, performing reset. Jun 9 22:29:34 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:29:34 localhost kernel: scsi0 : channel 0 target 0 lun 0 request sense failed, performing reset. Jun 9 22:29:36 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:29:36 localhost kernel: scsi0 : channel 0 target 0 lun 0 request sense failed, performing reset. Jun 9 22:29:36 localhost kernel: SCSI bus is being reset for host 0 channel 0. Jun 9 22:36:35 localhost syslogd 1.4-0: restart.
I am having this same exact problem. I can reproduce this consistantly by simply trying to burn an iso image with cdrecord. It happens regardless of whether I'm in X or not. My /proc/scsi/scsi file: ------------------------ Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: ATAPI Model: CD-R/RW CRW6206A Rev: 1.2A Type: CD-ROM ANSI SCSI revision: 02 ------------------------- If anyone needs me to test a possible fix, I'll be happy to, since I can reproduce this problem at will. It is important to note that burning a cd worked find under RH 7.0, 6.2, 6.1 etc. I keep a windows partition around for testing, and I can also burn cds under it as well without problems.
I'm also having the same problem. As root, running a 'cdrecord dev=0,0 speed=2 ./test.iso' produces a normal start, but at some point early in the burn process, SCSI errors begin and the machine is locked. It does not respond to the network or to the keyboard, and only a hard reset brings it back. However, this machine/burner combination worked perfectly under 6.2. This happens every time, but at different points in the burn. I don't have access to the box right now, but 'cdrecord -scanbus' reports the HP internal ATAPI burner correctly as 0,0,0. Thanks, Alvin...
(re: CD burning does not work under SCSI emulation with RH 7.1) Ok, I had a chance to look at the box today durnig lunch. This time, I tried turning the DMA off by doing a 'hdparm -d0 /dev/hdc'. This was mentioned as a possible work-around in another bug. This did not work at all. The drive didn't even start to write. Ok, so I turned the dma back on and tried to burn again in dummy mode only. 'cdrecord dev=0,0 speed=2 -v -dummy ./test.iso' Even this does not work, giving different errors each time I tried to run it. Several times I had to do a reset by doing a 'cdrecord -reset dev=0,0' Eventually, I can get the system to hang, even in dummy mode, with cdrecord returning an "OPC" error? Any ideas?
Same symtoms here, but slightly different problem. I can successfully write either a cd/r or cd/rw using cdrecord (both DMA and non-DMA). I use cdrecord with the eject parm to make nightly backups and sometimes in the morning, I wake up to a hung machine with the same messages in the log repeating every couple of seconds. I think it has something to do with midnight commander and magicdev as these are both hung up solid. I think they might be trying to read/get info from the drive while it's unavailable? I can't reproduce the prob. at will, however. Reboot solves the problem, but the kernel doesnt' cleanly unmount / or /dev/cdrom1. I found this bug report that also might be of interest: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=38314 Mike
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/