Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 54997 - [440GX motherboards are unsupported] Installer hangs when loading aic7xxx module
[440GX motherboards are unsupported] Installer hangs when loading aic7xxx module
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2001-10-23 21:30 EDT by Adam Herscher
Modified: 2005-10-31 17:00 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-10-25 06:25:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Adam Herscher 2001-10-23 21:30:35 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
Well, it looks like this problem was not fixed in Red Hat 7.2!

There's a whole slew of bugs - see 

Also see - http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=29555

I'm pretty bummed that 7.2 shipped broken.. I'm going to try dledford's 
boot images and see if they're compatible with the new 7.2 installation.. 
I really hope so, because I was looking forward to this working!

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

How reproducible:

Steps to Reproduce:
1. Boot 7.2 installer (cd)

Actual Results:  The installer hangs at "Loading aic7xxx driver..."

Expected Results:  The installer shouldn't hang.

Additional info:
Comment 1 Adam Herscher 2001-10-24 03:10:05 EDT
... and a few hours later ...

I was able to install 7.2 by passing the kernel the "apic" parameter.

However, once the install is done, the OS hangs while attempting to probe disks 
connected to the adaptec device (unfortunately I don't have logs handy, but I 
doubt they would provide any information that isn't in the huge description for 
bug id 29555).  I was also unable to successfully boot by passing the kernel 
the "apic" paramter through GRUB.

If I had time to pursue this further, I would likely attempt to boot the 
stripped down vmlinuz kernel with apic support, grab a clean kernel, apply 
Justin Gibbs' kernel patches (http://people.freebsd.org/~gibbs/linux/), 
compile/install the new kernel, and go from there.

I'm rather surprised that RedHat/Linux is having issues with this 
board/adapter - it's widely distributed.  If anyone has any simpler workarounds 
or suggestions, please clue me in.

Comment 2 Arjan van de Ven 2001-10-24 03:17:03 EDT
Unfortionatly there is nothing we can do. This is a bios bug where Intel refuses
to give us enough information to fix it ("it is Intel Proprietary Information"),
and for now Intel agrees that 440GX boards are officially unsupported in Linux.

"apic" in the boot disk USUALLY seems to work around the problem, but you must
install the SMP or Enterprise kernel in order to boot later, as the normal i686
kernel cannot have this option (it breaks on a LOT of other machines where,
technically, the bios isn't broken).
Comment 3 Adam Herscher 2001-10-24 03:51:26 EDT
Aye - that's rather ridiculous of Intel.  One would think they would do all 
they could to get their chips supported as widely as possible, especially if 
you've offered to flip the bill in developer cycles.

Is it enabling the apic support that would cause problems on non-broken bioses, 
or enabling SMP support?  Is SMP support enabled in the installer kernel?  I 
was able to pass the apic parameter successfully at that point.

Are there other ways to attain max useability with as little hacking as 
possible like detecting whether or not the system is using one of these 
chipsets and setting the kernel/options accordingly?

This seems to be a very widespread problem.  There are dozens of bugzilla cases 
on the topic (the subject is even used as the "good example" case description 
in your open bug form), and who knows how many have run into it but have not 
reported it.  Also keep in mind that VA Linux was shipping these boards in 
their boxes to the Linux-using world during the 6.2 (and possibly 7.0) days.  
None of these people can upgrade to 7.1 or 7.2, and VA Linux wiped their hands 
clean when they bailed on the hardware market.

Comment 4 Arjan van de Ven 2001-10-24 04:02:26 EDT
enabling apic support has 2 effects:
1) The APIC gets used (duh ;)
2) The MPTABLE (a table in the bios describing which pci slot has which IRQ
number, and some other info) is used instead of the PIRQ table (same purpose but
can do 1 CPU only) which appears to be broken for these boards

It's 1) that breaks in quite a few cases (mostly laptops) as it's not part of
the single cpu "pc standard" and bioses get surprised, usually related to
powermanagement. Unfortionatly the mptable is useless without APIC use, so it's
a very impossible situation untill the PIRQ table is fixed by a bios upgrade,
which Intel promised us to do.

Comment 5 Arjan van de Ven 2001-11-21 10:34:03 EST
closing bug as "WORKSFORSOME" as a workaround seems to work for you...

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