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):
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
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
is this a 440GX chipset?
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.
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)
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?
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 problem is not on the hardware.
RH7.2 do not install as well ( as well as slackware 8.1, gentoo 1.1a ).
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
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).
Additional for my comment. The issue with L440GX is when there is only one
processor in the board during install.
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
Is there a way to workaround this.
Will BIOS chipset update help.
Also, RedHat 6.2 works perfectly OK on this computer.
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...
>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.
will work with stock boot kernel
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.
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).
Thank you very much (really). That's the most coherent answer I've heard about
intel has given information so that the RHL9 and current errata kernels for
older releases should work