Bug 78415

Summary: (440GX IRQ_ROUTING)Installer does an infinite loop on quering SCSI device
Product: [Retired] Red Hat Linux Reporter: William M. Koos, Jr. <billy>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED DUPLICATE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0   
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: 2006-02-21 18:50:11 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 William M. Koos, Jr. 2002-11-22 16:21:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows 98)

Description of problem:
An upgrade from RH 6.2 to 8.0 resulted in an infinite loop when system tries to 
queue the SCSI devices.  The system I am upgrading is a VA Linux server FullOn 
2240 with an on motherboard adaptec AIC7896 SCSI controller using BIOS 
v2.57S2B3 (used for tape backup) and a PCI 
add-on Mylex AcceleRAID 150 SCSI controller using BIOS 4.10-50 and firmware 
4.08-0-37(used for RAIDed Hard drives).  The install seems to go flawlessly, I 
am able to upgrade the file system to ext3 and it appears to load the aic7xxx 
and DAC960 modules.  The system then reboots, GRUB comes up (from the hard 
drive), and then it starts to load RH Linux 8.  The following prints to the 
screen:
...
Loading scsi_mod module
SCSI subsystem driver Revision: 1.00
Loading sd_mod module
kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2
Loading AIC7xxx module
PCI: Assigned IRQ 11 for Device 00:0c.0
PCI: Sharing IRQ 11 with 00:09.1
PCI: Sharing IRQ 11 with 00:0c.1

PCI Assigned IRQ 11 for Device 00:0c.1
PCI: Sharing IRQ 11 with 00:09.1
PCI: Sharing IRQ 11 with 00:0c.0

scsi0: Adaptec 7xxx ...
scsi1: Adaptec 7xxx ...

Then it loops the next part forever with incrementing scsi ids

QINFIFO entries:
Waiting Queue entries:
Disconnected Queue entries:
QOUTFIFO entries:
Sequencer Free SCB List: 0 ... 31
Sequencer SCB Info: 0(c 0x0, s 0x47, l 0, t 0xff) 1(c 0x0, s 0xff, l 255, t 
0xff) ... 31(c 0x0, s 0xff, l 255, t 0xff)
Pending List:
Kernel Free SCB list: 210  or  310
DEVQ(0:3:0): 0 waiting
scsi 0:0:x:0 Command already completed   or   scsi 0:0:x:0 Attempting to queue 
a TARGET RESET message
scsi 0:0:x:0 is not an active device
aic7xxx_abort returns 0x2002  or  aic7xxx_dev_reset returns 0x2002


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Simply upgrade from a working 6.2 version to the 8.0 version on a system that 
has the adaptec AIC7896 SCSI controller and the Mylex AceeleRAID 150 SCSI 
controller
2.Or a full install on a clean hard drive yields the same result.
3.
	

Actual Results:  I receive no errors in the installation and everything seems 
to work fine when it boots off the CD.  The system restarts using the Hard 
drive to boot up, GRUB apears and kicks off the RH Linux initrd/kernel also 
located on the hard drive.  Then after loading the SCSI module, it tries to 
queue the SCSI devices and gets into an infinite loop incrementing SCSI IDs

Expected Results:  The kernel should see the SCSI devices and move on instead 
of siting in an infinite loop.  Since the SCSI devices work properly with RH 
6.2 and the installation kernel on the CD seems to have no problems with the 
SCSI devices, the new initrd/kernel shouldn't have a problem with the SCSI 
devices.

Additional info:

Due to the hardware working fine under RH 6.2, the install kernel having no 
problems with the SCSI devices, and the 'failed to exec modprobe' error, I 
believe that the SCSI modules did not get built into the initrd image 
correctly.  Bug report id 76284 is similar but really deals with the SCSI 
module not getting into the initrd image.

Comment 1 Matt Wilson 2002-11-24 19:49:49 UTC
kernel issue

Comment 2 Arjan van de Ven 2002-11-25 09:27:43 UTC
hardware/bios issue ;(
this machine has a 440GX chipset, right ?

Comment 3 William M. Koos, Jr. 2002-11-25 15:56:19 UTC
You are correct, it does have a 440GX chipset.

Comment 4 Alan Cox 2003-06-08 11:28:24 UTC

*** This bug has been marked as a duplicate of 79752 ***

Comment 5 Red Hat Bugzilla 2006-02-21 18:50:11 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.