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: Always Steps to Reproduce: 1.Boot to CD 2.hit enter to load install 3. Actual Results: system locks up Expected Results: continue after loading scsi driver Additional info:
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 devices. 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 post. 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? Miguel
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 and hangs. 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 kernel-BOOT-2.4.18-3.i386.rpm 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 this thing.
intel has given information so that the RHL9 and current errata kernels for older releases should work