Red Hat Bugzilla – Bug 54997
[440GX motherboards are unsupported] Installer hangs when loading aic7xxx module
Last modified: 2005-10-31 17:00:50 EST
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):
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.
... 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.
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).
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.
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.
closing bug as "WORKSFORSOME" as a workaround seems to work for you...