Description of problem:
Fedora Core 6 does not support two sets of hardware on a IBM eserver xseries 300:
S3 Savage 4 Pro video on system board
Dual Intel 'e100' cards on system board.
Fedora Core 4 will properly identify hardware during install as well as
configure and use them at runtime, whereas FC6 will fail to identify the Savage
4 card and revert to curses install mode (Headless). The e100 cards will fail to
identify and no device operability is shown (ifconfig shows no devices
available, even with module installed).
Version-Release number of selected component (if applicable):
FC6 Install CD
Steps to Reproduce:
1.Run the FC6 installer with no kernel options on a IBM eServer xseries 300
2.Note the installer revert to headless mode
3.Reboot after install, and attempt to configure the eth0 and eth1 devices with
proper modules loaded.
4. Repeat Steps 1-3 with FC4 disks and note differences.
Anaconda starts in headless mode, unable to connect to network after install
Anaconda should be able to start in X mode, should be able to connect to network
How does rawhide work?
Created attachment 147932 [details]
lspci output with acpi=off passed to the bootloader
Also, running lspci in the shell without passing "acpi=off" to the kernel
In reference to comments 2 and 3:
Disabling ACPI with the kernel option acpi=off allows anaconda's hardware
detection to work properly, identifying both the e100 and the savage4 hardware.
The above attachment shows lspci's results when ACPI is disabled. When run
without the option, lspci returns nothing.
Can you attach the anaconda.log file pls?
I was requested by sgrubb to complete an FC6 install on the machine using
acpi=off so that I was able to update the machine using yum. The update
completed, installing the current 2.6.19-1 kernel. Booting into the new kernel
without the boot option still results in the same problems, where the e100 cards
are not identified(ifconfig returns only lo) and lspci returns nothing. Booting
into the kernel with the option (acpi=off) still successfully allows the
hardware to work again, with lspci returning results identical to the attachment
above. In short, the current kernel fixes nothing.
In reference to Comment 5 (request for anaconda log): I will have the results to
post from both installs (with and without kernel option acpi=off) on Wednesday.
Did you try 'ifconfig -a' instead of just 'ifconfig'?
(In reply to comment #8)
> Did you try 'ifconfig -a' instead of just 'ifconfig'?
Both. Nothing is returned except for loopback in both cases.
Created attachment 148055 [details]
anaconda log from install with no additional kernel options
Created attachment 148057 [details]
anaconda log from install with apci=off
Two more items pls:
- the output of 'lspci -vn'
- and the output of running 'dmesg'.
Should have asked earlier but forgot, sorry.
Just to summarize it with 'acpi=off' you can install/see devices without
trouble. It is only when don't specify anything that nothing is seen?
What version of the BIOS do you have? Do you have the latest version?
What happends when you use 'nolapic' as a bootup argument (without adding
(In reply to comment #12)
> Two more items pls:
> - the output of 'lspci -vn'
> - and the output of running 'dmesg'.
> Should have asked earlier but forgot, sorry.
lspci -vn returns nothing with normal options.
dmesg output of both modes attached below.
Created attachment 148337 [details]
dmesg output with normal kernel options
Created attachment 148338 [details]
dmesg output with acpi=off
Created attachment 148339 [details]
dmesg output with normal kernel options
(In reply to comment #13)
> Just to summarize it with 'acpi=off' you can install/see devices without
> trouble. It is only when don't specify anything that nothing is seen?
> What version of the BIOS do you have? Do you have the latest version?
I have ABE117A. The current version is ABE120A. According to IBM website
the update was made for MS certification testing. If necessary, I can update the
BIOS and see what changes.
> What happends when you use 'nolapic' as a bootup argument (without adding
> 'acpi=off') ?
Success. That kernel option provides the same result as acpi=off, such that the
I would be curious to see what the dmesg output is when you use 'lapic' as
acpi=off is the more "big hammer" approach, while lapic just turns off one part
of the ACPI initialization.
In regards to the BIOS, please upgrade it. Windows certification means "Vista
certification" and possibly updating the BIOS ACPI and MPT tables so that Vista
can run. In many ways Vista depends on the BIOS ACPI to configure much more
functionality, in a same manner as Linux depends on the BIOS to figure out if it
should use the LAPIC or the legacy interrupt controller.
So sorry for making you do more stuff, but can you do:
1). include the dmesg when running with 'lapic'
2). include the output from /proc/interrupts when running with 'lapic' and when
running without 'lapic'
3). upgrade the BIOS and try to run the kernel without any bootup options.
4). Go in the BIOS and see if there is a 'Run in compatible layer" or 'Run in
UNIX configuration'. Some of the older Compaq's had this (and you needed it to
run Linux on them) and I wonder if this older box might have something similar
Replace where I said 'Vista' with 'Windows Server 2003'.
Created attachment 148497 [details]
dmesg with kernel option "nolapic"
Created attachment 148498 [details]
contents of /proc/interrupts with "nolapic" option
Created attachment 148500 [details]
contents of /proc/interrupts with no additional kernel options
I upgraded the BIOS to version ABE120A, which is the latest available on the IBM
website. When I did so, the kernel failed to boot, hanging on the message:
"agpgart: detected VIA Apollo Pro 133 Chipset".
This occurs regardless if I use boot option "acpi=off" or not.
This phenomena has been confirmed on other eserver xseries 300s when the BIOS
has been updated to the same version, when attempting to boot with Fedora 6.
Therefore, the BIOS update results in an unusable system.
The work-around where you pass in 'lapic' and use the earlier BIOS version is
the safest bet right now.
Looking at the dmesg and the Linux code I am not sure if the problem is with
BIOS ACPI code or the Linux ACPI interpreter being too anal.
I don't have this box here so I cannot do any debugging of this unless you are
willing to spend more time and collecting information from a debug kernel that I
can supply to you.
Please keep in mind that this might take months before a resolution is found,
and the resolution might be: use lapic b/c the BIOS code is busted and this box
is too old to roll a new BIOS.
One thing that I neglected to mention is that having the 'nolapic' option does
not decrease the performance. The 'nolapic' skips initialization of the IRQ
lines and uses what the BIOS sets. In the case of the x300, the BIOS sets it to
use IO-APIC (which is good), and that is what the Linux kernel would use (and
not try to parse the BIOS LAPIC entries - which somehow after initializing are
missing the IRQs for a couple of devices).
What would have been terrible was if you saw 'XT-PIC' in the /proc/interrupts.
That would be using the legacy PIC controller which is limited in its functionality.
Lastly, in comment #25, when reading please replace all 'lapic' strings to
'nolapic'. I think starring at too much code made me confuse the variables in
the kernel with the bootup arguments. Sorry about that confusion.
In summary, I am going to close this BZ as WORKSFORME since there is a
work-around (passing 'nolapic' as the bootup argument). If I get the hardware in
my hands I can take spend more time on finding the culprit.