From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 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 no effect. 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 without problems. The GRUB menu item for the SMP kernel is unmodified from what was installed: title Fedora Core (2.4.22-1.2115.nptlsmp) root (hd0,1) kernel /vmlinuz-2.4.22-1.2115.nptlsmp ro root=LABEL=/ hda=ide-scsi rhgb initrd /initrd-2.4.22-1.2115.nptlsmp.img Version-Release number of selected component (if applicable): kernel-2.4.22-1.2115.nptl How reproducible: Always Steps to Reproduce: 1.Turn on computer 2.Select SMP kernel from Grub menu 3. Actual Results: System does not boot, hangs after very first loading kernel message Expected Results: System boots normally as it does with the non-smp version of the same kernel Additional info: HARDWARE: 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 Other OS: 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 same thing. 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 precision 410
The Dell Precision 410 has garbled ACPI tables in the BIOS: http://bugzilla.kernel.org/show_bug.cgi?id=1434 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: http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/ 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. thanks, -Len
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
Hi Roger, 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]) Checksum OK 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 succeed. Thanks, -yi
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 Hi, 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! -yi
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 persists. 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/