Red Hat Bugzilla – Bug 109550
SMP kernel boot failure on Dell Precision 410
Last modified: 2007-11-30 17:10:33 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Description of problem:
After a fresh install of Fedora Core 1, the supplied SMP
kernel fails to even load. After the GRUB screen, I see
very first loading kernel message and the nothing else. No
OOPS, no diagnostics, nothing. The machine requires a
reset with the hardware switch (i.e) CTL-ALT-DEL has
The non-smp kernel boots without problems. The latest
2.6.0-test9 SMP kernel exhibits the same non booting
behavior but the 2.6.0-test9 non-SMP kernel boots
The GRUB menu item for the SMP kernel is unmodified from
what was installed:
title Fedora Core (2.4.22-1.2115.nptlsmp)
kernel /vmlinuz-2.4.22-1.2115.nptlsmp ro root=LABEL=/
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Turn on computer
2.Select SMP kernel from Grub menu
Actual Results: System does not boot, hangs after very first loading
Expected Results: System boots normally as it does with the non-smp
version of the same kernel
Dell Precision Workstation 410
Dual 500Mhz Pentium III
512 Megabytes Memory
440BX/ZX/DX - 82443BX/DZ/DX Host bridge
Adaptec AHA-2940U2/U2W/7890/7891 SCSI
Radeon 7200 Graphics card
Sound Blaster Live Audio card
3C905 onboard ethernet
Two SCSI LVD Hard Drives
Two IDE CD-ROM Drives
Windows 2000 installed and boots/functions normally
I have some experience building kernels so I can test
things with some guidance.
Just to let you know I have the same machine and the same exact
problem (pc boots fine with non-smp kernel but refuses to boot with
the smp flavor). I just upgraded to the latest 2129 and still sees the
The boot process stops at:
Uncompressing Linux... Ok, booting the kernel
My two processor Dell precision 410 also. problem exists with both
2115 smp kernel and 2149 smp kernel
I have a Dell Percision 610 and the exact same problem. Problem
exists with both 2115 smp kernel and 2149 smp kernel.
I have a dell 1650 with the 2166 kernel and had the same issues with
SMP kernel not booting. It hangs during mountin file systems.
My Precision 650 also hangs on boot. With no added kernel parameters,
it hangs at the "initializing firewire controller" message. If I add
"nofirewire" it hangs at "setting up swap space". I've tried
"acpi=off" and "noapic" and still cannot boot the smp kernel (2166, 2174).
I have a Precision 410 with the same problem. I've tried ticket 109693
(http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=109693) to no avail.
Ran `yum update' (with fresh FC install) and it installed kernel-smp
2.4.22-1.2174.nptl.i686 and had the same problem.
Same system here (Precision 410), same problem. However, disabling
ACPI in the BIOS will allow the SMP kernels to boot fine.
Strangely, though, the Knoppix 3.3 bootable CD distro can boot its SMP
kernels on this system *without* disabling ACPI in the BIOS....
I disabled ACPI in BIOS, and it worked as well. SMP kernel now boots
fine. Dell Percision 610.
I disabled "Power Management" in the BIOS, and it did not work. Dell
Precision 210 dual 450MHz CPU. I tried everything mentioned in this
defect, and it does not work for my machine.
Decided to try installins SuSE, it froze, so I went back to FC 1. Went
to install, decided to upgrade instead of a fresh install.
Tried the BIOS tweak above, (I already had ACPI=off in grub.conf) and
it didn't do anything. Turned ACPI back on in BIOS, and it boots fine.
It didn't boot the SMP before I tried SuSE. Not sure if trying to
install SuSE matters, or if updating mattered.
Coworker turned ACPI off in BIOS, and it works fine.
I disabled ACPI in BIOS, and SMP kernel now boots on two processor
The Dell Precision 410 has garbled ACPI tables in the BIOS:
This box is older than the ACPI cutoff date, but there is
a bug in Fedora Core 1, fixed in later kernels, such that
and old BIOS sets acpi_disabled=1, but does not
clear acpi_ht=0. So the SMP kernel proceeds to parse
the ACPI tables to see if it can enumerate the processors
to enable HT. The kernel crashes parsing the tables
before any kernel output.
manual "acpi=off" on the cmdline should prevent this,
as will booting with the BIOS ACPI support disabled.
That said, I think it is possible for ACPI to be hardened
and detect this garbled table, and keep running. In
this case it is a bad MADT, so ACPI would run as if
the user typed "pci=noacpi".
I'll try to make Linux detect and survive the Dell 410 table
and will post the fix to the bug report above if the 410 owners
would like to try it out. Unclear if the Dell 210 is the same issue,
if you attach the output from acpidmp from pmtools, I can check it out:
I can't explain the run-time Dell 650 and 1650 failures above --
different bug. Let me know if they work with "acpi=off"
but fail otherwise.
This work-around is very inconsistent. It works, then it doesn't.
Having ACPI off in BIOS and no ACPI command in GRUB will boot, then it
won't. Then maybe you'll have to turn off ACPI in BIOS, and put the
command in GRUB and it'll work, or it won't...
Doesn't seem to have any rhyme nor reason to it. I've been trying to
make sense of it all day.
Have vga=791 on one machine, coworker doesn't have that, both are just
as goofy. Same systems.
Created attachment 98828 [details]
Output from acpidmp tool from pmtools
If you need more information, I will do anything I can
Your dell 210 MADT is garbled the same way as above dell 410 and 610.
ACPI: APIC (v001 DELL WS 210 0x00000002 ASL 0x00000061) @ 0x(nil)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
ACPI: IOAPIC (id[0x02] address[0xfec00000] global_irq_base[0x0])
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x4])
Since Len said there was a "disable acpi_ht" bug in fedora core 1
kernel, would you please try a vanilla 2.6.5 kernel and patch with
below patch to see if it boots your system? Please provide dmesg if
Created attachment 99551 [details]
survive after detect a garbled MADT from BIOS
The patch will try to survive after detecting a garbled MADT.
If the garbled entry is a lapic entry
both acpi_lapic and acpi_ioapic are set to zero (disabled)
else if the grabled entry is a ioapic entry
only acpi_ioapic is set to zero (disabled)
Created attachment 99588 [details]
Intensive check for garbled MADT
For anyone who can reproduce the bug, would you please help to test this patch?
This patch will do intensive check for a grabled MADT and is supposed to
survive the system after that.
This patch is against 2.6.5 kernel. Let me know if you need a 2.4 kernel patch.
Really need your help and thanks in advance!
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/