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 http://bugzilla.redhat.com/bugzilla/buglist.cgi? product=Red+Hat+Linux&version=7.1&allexcept=1&bug_status=NEW&bug_status=VER IFIED&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_statu s=CLOSED&bug_status=NEEDINFO&email1=&emailassigned_to1=1&email2=&emailrepor ter2=1&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=aic7x xx&long_desc=&bug_file_loc=&status_whiteboard=&cmdtype=doit&order=Bug+Numbe r+Ascending&form_name=query 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: Always Steps to Reproduce: 1. Boot 7.2 installer (cd) 2. 3. Actual Results: The installer hangs at "Loading aic7xxx driver..." Expected Results: The installer shouldn't hang. Additional info:
... 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. Thanks
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...