From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2a) Gecko/20020913
Description of problem:
After upgrading to RedHat 8.0 the machine no longer boots. The system is one of
the VA Full-On servers (single processor) with the Intel L440GX motherboard, and
the DAC 960 raid controller. Neither the smp or single processor kernels will
boot. The single processor kernel dies with adaptec driver errors (this is the
apic problem again), while the smp kernel hangs right after the Real Time Clock
driver loads. Attempting to boot into single user mode yields similar results,
but I get an additional line after the Real Time Clock line:
oprofile: APIC was already enabled
It looks as though it may be the APIC problem in another form (again).
I have been running the smp kernel on this system to get around the apic problem
in prior kernels. But that doesn't seem to work here.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Upgrade to RedHat 8.0
2. Boot upgraded system
Created attachment 82624 [details]
.config to build a custom kernel for (single processor) L440GX+ motherboards
I have attached above a .config for a custom kernel (from the 2.4.18-17.8.0
source tree) that will work on single processor systems that use the L440GX+
motherboard. *NOTE* A number of modules have been disabled from being built
simply because I don't need them....
This .config *only* applies to L440GX+ systems with single processors, the stock
smp kernel works just fine on dual processor L440GX+'s, but does not work on
motherboards with only a single processor (and of course, the stock non-smp
kernel rpm does not work on the L440GX+ at all)
Basically there are only 3 important changes...
1. Disable SMP support
2. Enable local APIC support for uniprocessors
3. Enable IO-APIC support for uniprocessors
Then build and install the custom kernel.
I should also add that the kernel-BOOT rpm works, but since it lacks support for
a number of things (like nfs) it isn't really a suitable work-around.
Created attachment 82725 [details]
boot-up messages from a successful boot (2.4.18-14BOOT)
I'm seeing the same behavior with a fresh install from the 8.0 CDs. The
install goes fine, but subsequent boots hang; the last message is "Serial
driver version 5.05c...". This is on a VALinux 1150 (one CPU, L440GX+
motherboard) without a DAC960; I may be trying the install again on a VALinux
box with a DAC960 soon.
I was able to install and boot RH7.3 successfully on this same machine by using
the APIC/SMP-kernel workaround, but that no longer works with 8.0. The
behavior is slightly different between the SMP and non-SMP kernels, though;
with the SMP kernel I get up to the "Serial driver..." message (as I mentioned
above), but with the non-SMP kernel I get the SCSI timeouts that always used to
happen with RH 7.x on this hardware.
It would seem to be a step backward that the workaround that was working with
7.x is no longer working in 8.0; people with single-CPU VALinux hardware are
now left out in the cold, with only the possibility of a custom kernel to make
it possible to install 8.0.
Is anyone at RedHat in contact with Intel over the L440GX+ issue?
> Is anyone at RedHat in contact with Intel over the L440GX+ issue?
We were. "Intel Proprietary Information" is needed to fix this issue and we're
not going to get it. Complain to vendor please.
I'm aware that RedHat contacted Intel at one point and asked about resolving
the bug, but I was actually asking whether anyone at RedHat is "in contact"
with Intel--in other words, continuously in contact, keeping after them, until
this problem is resolved. Even though this may be more Intel's issue than
RedHat's, the fact is that it makes it impossible to use RedHat on a popular
motherboard, and it's been going on for well over a year now, so it would seem
worthwhile for RedHat to actively pursue it with Intel.
The fact that the SMP-kernel/APIC workaround no longer works with uniprocessor
VALinux hardware and RH8.0 makes it even more urgent for those of us who want
to upgrade this hardware. Do you have any idea *why* this no longer works? As
I said, it's a bad sign...up until now there's been slow forward progress in
workarounds/compatibility, but RH8.0 is the first step backward.
Since these are systems made by VA Linux and since VA Linux is no longer
selling these, is there a contact at Intel you can point us at? I have no
problem complaining I just need to know who to bug.
The exact same problem happened when I ran up2date on my 7.3 system to bring in
the new 2.4.18-17.7.x kernel. The SMP kernel hangs after the "oprofile: APIC
was already enabled" message, and the UP kernel gets SCSI disk errors. I've
backed off to the 2.4.18-3smp kernel which I was running before.
Looking for the oprofile message in the source suggests to me that the problem
is happening when the oprofile module configures the NMI interrupt. The hang
certainly happens within oprofile, as the final "oprofile 0.2 loaded" message
never appears. It would be nice if there were some way to disable the oprofile
initialization, as it does not appear to be necessary.
FWIW - I have exactly the same symptoms as email@example.com only updating RH7.3 to
the 2.4.18-18.7.xsmp kernel (L440GX motherboard running a single processor).
Tried booting with the "noapic" option. Got past the hang at "oprofile: APIC
was already enabled" message but went into the hang on endless SCSI check loop
instead (using Adaptec AIC-7896 SCSI controller - see, for example, Bug
Also tried the up version of the newer kernel. also wound up with the endless
SCSI check loop.
Like Ian, I've also gone back to 2.4.18-3smp kernel for now (works fine). If I
find myself with wads of time on my hands (hah), I might try compiling my own
kernel using rod's config.
Has anyone with this problem tried the latest BIOS for this board (Release 14.3
build 133)? I'm using release 14.0, build 129 and have been hesitant to bother
with an update, but if someone had expressed success, I'd be more likely to
give it a try.
Where are BIOS updates for these boards available? I have looke at Intel's
site and could not find anything wrt these boards. Do they actually make a
difference? So far the only success I have had is building a custom kernel and
enabling the apic support as described above.
*** This bug has been marked as a duplicate of 75947 ***
I found (but haven't tried yet) BIOS upgrades at:
more specifically at:
I updated to the latest BIOS.
Same error. Infinite SCSI check loop.
So no use if you updated the BIOS.