Intel LB440GX Server Platform

I recently purchased a new server to replace our current underpowered ASL machine based up on the LB440GX motherboard with an adaptec AIC-7896 scsi controller. This controller uses the aic7xxx driver which proceeds to put the installer into a loop:


Apr 21 10:51:25 monster kernel: scsi0:0:1:0: Attempting to queue an ABORT 
message
Apr 21 10:51:25 monster kernel: scsi0:0:1:0: Command found on device queue
Apr 21 10:51:25 monster kernel: aic7xxx_abort returns 8194
Apr 21 10:51:58 monster kernel: scsi0:0:1:0: Attempting to queue an ABORT 
message
Apr 21 10:51:58 monster kernel: scsi0:0:1:0: Command found on device queue
Apr 21 10:51:58 monster kernel: aic7xxx_abort returns 8194
Apr 21 10:52:33 monster kernel: scsi0:0:1:0: Attempting to queue an ABORT 
message


It continues this way for about 20 minutes going through all 15 scsi id's on both channels before getting into the ASL installer and erroring out by stating that there are 'no hard drives available'. 

Now I know ASL is not based on Red Hat, but the gang over at RedHat discovered this problem with their RH 7.1 release, as well as a work-around for the problem which is basically stated here (large):

For clarification sake, it's not that the BIOS is mapping IRQ's wrong, and it's
not that we have lost any functionality since the 2.2 kernel PCI code.  Quite
the opposite, it's that PCI functionality has been added since the 2.2 kernel. 
Specifically, the 2.4 kernel supports the notion of hot-plug PCI devices.  That
requires that the kernel PCI layer know about/assign all the address space and
IRQ resources to the various slots so that if sometime after booting up someone
adds a new PCI card that has a PCI bridge chip, then the PCI layer has to be
able to assign I/O and IRQ resources to the bridge chip itself, and those I/O
and IRQ resources have to come from the pool of resources already allocated to
the bus that the card was plugged into.  So, in order to insure that we will
always be able to accept a hot plug card, the PCI layer in the 2.4 kernel now
re-organizes those PCI resources at boot time to make sure that it is possible
to plug a card with a PCI bridge chip into every PCI slot if the user so
wishes.  In this process, the PCI code in the 2.4 kernel is evidently messing up
the IRQ assignment on the Adaptec chipset.  This *only* happens on the L440GX
motherboard from Intel as far as we can tell, and the root cause of the mistake
hasn't been isolated any further than what I've told you here.  The reason that
enabling SMP or UP-IOAPIC support solves the problem is that when IOAPIC support
is enabled (which happens automatically with SMP support, or explicitly with UP
kernels if you turn on UP-IOAPIC support), it runs *after* the PCI resource
allocation code, and it re-routes the interrupts according the the computers MP
table.  By doing that, it undoes whatever mistake the PCI code is making, and
things work.  *THIS IS NOT A FIX*  The fact that it undoes the mistake the PCI
code makes does not make the PCI code any better!  The PCI code still needs
fixed.  The whole reason we don't ship our boot kernel with IO-APIC support
enabled is that there are a number of boards out there that won't boot with
IO-APIC support enabled.  They happen to mostly be older UP boards that try to
use IO-APIC interrupts on their UP system and have bad/unusual MP tables that
confuse the IO-APIC code in the kernel, so if you are only interested in a
subset of the machines that Red Hat supports (such as SGI is), then you can
ignore them and ship with IO-APIC support enabled.  We can't do that.  We need
to find a real fix.  I don't expect that in the near term though, so our
proposed workaround (which we are testing) is an IO-APIC enabled kernel that by
default doesn't use the IO-APIC, and you need to boot the kernel with the option
"apic" to make it use the IO-APIC and hence work on the L440GX motherboards. 
Once we've confirmed that this kernel *doesn't* blow up on machines that have
known bad IO-APIC MP tables, we'll build a new kernel with munged kernel symbol
versions so that it will load the modules on the CD and then release that as the
workaround.


The entire bugzilla report can be found here, and is an interesting read    [;)]    

bugzilla report

This 440GX chipset is used on a large number of servers, and supposedly intel has been made aware of this problem, but it seems it is possible to come up with a work around for the pci routing problem.. unfortunately it looks like a pretty in-depth solution that can't be done easily. The shipping redhat 7.1 cd's lockup on my machine during the same phase as the ASL install, but the newly released redhat 7.1 boot.img rectifies the problem. This issue is not limited to Red Hat, as it is affecting most if not all linux distro's based on the 2.4.x kernels, although it is seems to be limited to the L440GX chipset. 

My question is, is there any hope for me? Is there any kind of work around I can use with the ASL installer?? Maybe some way to enable UP-IOAPIC support during install? I really really want to get this to work, and I can't believe this issue hasn't come up on the forum before. (although I have looked extensively..) Sorry about the long post, just wanted to give as much information as possible. Thanks!

chronos@run-with-the-devil.com
www.run-with-the-devil.com

[ 19 November 2001: Message edited by: Chronos ]

This thread was automatically locked due to age.