Bug 67235 - Installer hangs on aic7xxx, similar to bug 29555
Summary: Installer hangs on aic7xxx, similar to bug 29555
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2002-06-21 13:25 UTC by Need Real Name
Modified: 2007-04-18 16:43 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-06-07 18:46:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2002-06-21 13:25:58 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)

Description of problem:
I've installed 7.1 on this server platform and had to use the resolution in bug 
29555 to get around and install it.  I was hoping that 7.3 fixed this issue but 
it appears that the same thing is happening.  It attempts to load the aic7xxx 
and hangs during the installer run.  This is an Intel system board with two 
built in SCSI adapters.  I also have a megaraid 300 controller that is driving 
the drives.  I do not have anything hooked up to the on board SCSI.  Disabling 
SCSI adapters has no effect.

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

How reproducible:

Steps to Reproduce:
1.Boot to CD
2.hit enter to load install

Actual Results:  system locks up

Expected Results:  continue after loading scsi driver

Additional info:

Comment 1 Need Real Name 2002-06-21 14:44:07 UTC
After about 15-20 minutes the installation continued.  I finished the 
installation and rebooted.  It started to come up then says:

aic7xxx_abort returns 0x2002
... bunch of machine code ( I wish I could cut and paste )
SCSI device set offline

This reminds me very much of the SCSI timeout from bug 29555

Comment 2 Arjan van de Ven 2002-06-21 15:52:46 UTC
is this a 440GX chipset?

Comment 3 Need Real Name 2002-06-21 15:58:23 UTC
Ok, this should be the last update.

The systemboard is a 440GX.

It looks like it went through the 2 channels (15 devices each channel) with the 
previous message.  (This took about 20 minutes to get passed) Then it loaded 
the megaraid and continued with the boot process.  Now it's stuck loading Eth0 
adapter and has been for about 30 minutes.

One last piece of information.  The installer didn't auto detect the megaraid 
card, I had to manually select it.

Comment 4 Arjan van de Ven 2002-06-21 16:01:56 UTC
1) did you use the "apic" command line option ?
2) can you send the output of the dmidecode program
(http://people.redhat.com/arjanv/dmidecode.c or part of kernel-utils package) so
that we can add your bios to the blacklist
3) you HAVE to install the SMP kernel on 440GX boards

(we can't actually really fix this issue, just work around it, it's a bug in the
intel bios, using "apic" and the smp kernel should work around it just fine)

Comment 5 Need Real Name 2002-06-27 13:49:48 UTC
I had the same problem with the installer, but have never had a problem using
the Intel L440GX+ motherboard with other Linux distros.  When I used the
2.4.18-3smp kernel, I had to use 'Linux noprobe' to install and after
installation I did not get the aic7xxx module installed on boot.  I was able to
use the kernel, but my hard drive lights remained on all the time.  (By the way,
I'm using ide hard disks, I'm using the SCSI for other stuff)  When I upgraded
to 2.4.18-5smp the problem was no longer there and I'm back to normal.  There
seems to be a problem with the installation kernel which has apparently been
fixed in version 2.4.18-5smp.  I have built my own kernels for this board in the
past and faced no unusual problems.  But I always loaded the SCSI module on
boot.  Does the installation kernel normally have SCSI built in.  Would'nt that
solve this problem?

Comment 6 Need Real Name 2002-07-04 21:14:33 UTC
I have exactly the same problem, with a DFI P2XBL/D , dual P2@350, _BX_ 
chipset. The SCSI adapter is a AHA-29160N. The RH7.3 installation starts, the 
module is invoqued, a lot of timeouts occur and finally the kernel panics.
"apic" and "noprobe" do not work. The new module crashed the kernel minutes 
later, due to the timeouts, and the old module just gives CRC errors in all 
the devices.
The problem is not on the hardware.

RH7.2 do not install as well ( as well as slackware 8.1, gentoo 1.1a ).

Comment 7 Need Real Name 2002-07-04 23:09:36 UTC
please disregard the previous post. my problem was solved, but I still think 
there may be some strange bug around.

I have the following hardware setup:

CDR , 50pin , ID 3 , SYNC 10
Quantum Atlas IV, 9GB, SYNC 40 ( 68pin LVD )
IBM UltraStar 18GB, SYNC160 ( 68pin LVD )

All scsi stuff was set up as SYNC 160 on the SCSI board. Windows XP installed 
itself perfectly ( with that setup ). Linux crashed, as I wrote n my previous 
Now that I changed 160 to 40 on the Atlas disk, linux boots perfectly.
Shouldn't the driver confirm the device type before doing what's on the 
AHA29160N memory?


Comment 8 Need Real Name 2002-08-13 10:23:15 UTC
I experienced the same with intel board L440GX, when loading the aic7xxx driver
the system hangs. The same problem as with rh7.1 (and slackware 8.1 that also
uses  a 2.4.xx kernel, slackware 8.0 uses 2.2.19 kernel and doesn't have the
problem just like redhat 6.2).

Comment 9 Need Real Name 2002-08-13 10:33:23 UTC
Additional for my comment. The issue with L440GX is when there is only one
processor in the board during install.

Comment 10 Need Real Name 2002-08-13 11:07:45 UTC
I have similar problem. with RedHat 7.3 installation CD.
Installer hangs on 

SCSI : Adaptec-7896 Version 2.57S2B3
MB : Intel 440GX

It says: loading aic7xxx
and hangs.

Is there a way to workaround this.
Will BIOS chipset update help.

Also, RedHat 6.2 works perfectly OK on this computer.

Comment 11 Arjan van de Ven 2002-08-13 11:13:01 UTC
L440GX chipset motherboards require the "apic" commandline option to work around
a blatent bios bug, and you need to install the SMP kernel. You should ask Intel
if they released a fixed bios yet...

Comment 12 Need Real Name 2002-08-13 11:30:28 UTC
>L440GX chipset motherboards require the "apic" commandline option to work around
>a blatent bios bug, and you need to install the SMP kernel. You should ask Intel
>if they released a fixed bios yet...

Thank you very much for this. The only question I have:
If I add "apic" option to the standard boot image 
which is used for installation - will it work or 
I should create a different boot image for installation.

Comment 13 Arjan van de Ven 2002-08-13 11:32:48 UTC
will work with stock boot kernel

Comment 14 Need Real Name 2002-08-13 13:51:08 UTC
The 2.4.18-5 kernel works.  I had this problem until I upgraded the kernel. 
There is a problem with the installation kernel.  The L440GX+ needs the SCSI
module or the driver built in order to operate properly.  RedHat needs to fix
their installation disk and not continue with this APIC workaround story.  I
used a custom built 2.4.x kernel with Slackware 8.0 and had no problems with the
aic7xxx SCSI system.

Comment 15 Arjan van de Ven 2002-08-13 13:55:25 UTC
Maybe you missed the fact that we keep adding bios idents to the workaround
table. And yes you can easily compile kernel that just works, all you need to do
is enable the "enable local apic for uniprocessor" config option. We can't do
that however since it breaks quite a few laptops out there. (The effect of this
option is that the broken $PIR bios table is not used but that the MPTABLE bios
table is used instead, the "apic" option has this exact same effect).

Comment 16 Need Real Name 2002-08-14 04:32:52 UTC
Thank you very much (really).  That's the most coherent answer I've heard about
this thing.

Comment 17 Arjan van de Ven 2003-06-07 18:46:07 UTC
intel has given information so that the RHL9 and current errata kernels for
older releases should work

Note You need to log in before you can comment on or make changes to this bug.