Red Hat Bugzilla – Bug 138998
Anaconda installs SMP-Kernel on a HT system with disabled HT
Last modified: 2007-11-30 17:07:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Description of problem:
After installing RH EL 3 on a Pentium-4 workstation I have the effect,
that Anaconda installed the SMP kernel and configured it as the
default kernel in GRUB. The problem with this is, that this
workstation has no SMP, its just a Hyperthreading-CPU but
Hyperthreading is disabled inside the systems BIOS. So I expected that
a normal uniprocessor kernel would be installed, but instead I end up
with a SMP kernel that crashes after reboot.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Turn off Hyperthreading in BIOS
2. Install Red Hat EL 3.0 WS from CD
Actual Results: SMP-Kernel gets installed, and that is wrong.
Expected Results: Uniprocessor-Kernel gets installed.
I wonder if problem is caused by the system BIOS. Can it be that BIOS
delivers a wrong MP table that makes Anaconda "think" that its
installing on a SMP system? Is there a way to get information what the
BIOS delivers to Anaconda?
anaconda gets the information by doing a cpuid call and then checking
the number of siblings reported. So if the BIOS is saying that there
are >= 2 siblings, then we detect HT as being present.
Is the BIOS doing the right thing here and only reporting one sibling
in cases where HT is disabled.
I checked the in the source of anaconda and stripped down the smb.c
file so that only the detectHT subroutine remained and compiled a
small program that showed me the return value of that sub. Its always
"1" if a HT capable CPU is plugged into the system, and of course
that's logical. Invoking a CPUID instruction is performed on CPU
level, there is *no* BIOS involved, so whatever I do with enabling or
disabling HT in the BIOS it doesn't matter. CPUID gets the values
directly from the CPU and the CPU doesn't know what the user
configured at BIOS level.
The impact of this decision is that now a SMP kernel is installed if a
HT capable CPU is present, no matter what the user disables in the
BIOS. Unfortunately both the SMP versions of 2.4.21-15 or 2.4.21-20
(just updated via RHN) crash when I try to start the system with the
SMP kernel. I just reach a line where it says
"Total Huge TLB memory allocated, 0"
and there the system stops.
I tried the same settings with both old and new versions of Knoppix
which always boots a SMP kernel. Kernels 2.4.20 and 2.4.27 from
Knoppix worked well and didn't crash.
So as far as anaconda is conernced I would put down the priority of
the bug to "low" since its a bug, but it shouldn't harm that much. On
the other hand I will try to find out what's going wrong in the kernel
and issue a bug against kernel 2.4.21-20 soon with high priority since
I think that's the real "bug" to be solved. My customer won't complain
about running a SMP kernel if it wouldn't crash. :-)
Unfortunately, if the cpuid doesn't change, then there's not a good
hardware-independent way for me to discover it. I agree that fixing
the SMP kernel is the right thing to do :)