Bug 44042

Summary: (IDE IDE-SCSI)kernel hangs w/ cd-rw with ide-scsi emulation
Product: [Retired] Red Hat Linux Reporter: Leo Lopes <leo>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED CURRENTRELEASE QA Contact: Brock Organ <borgan>
Severity: high Docs Contact:
Priority: medium    
Version: 7.1CC: alvin, djuran, johnchristopher, msobik
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-09-30 15:39:02 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 Leo Lopes 2001-06-10 14:47:11 UTC
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.

Comment 1 Need Real Name 2001-06-24 12:28:55 UTC
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.

Comment 2 Alvin P. Phillips 2001-09-26 13:05:57 UTC
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...

Comment 3 Alvin P. Phillips 2001-09-28 18:49:50 UTC
(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?

Comment 4 Michael Sobik 2001-10-12 21:12:50 UTC
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


Comment 5 Bugzilla owner 2004-09-30 15:39:02 UTC
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/