Most recent kernel where this bug did *NOT* occur: not known, I've tested only 2.6.20.7 release and the aforementioned kernel version. Distribution: doesn't matter - a kernel bug Hardware Environment: CPU: AMD Athlon 64 4200+ EE CPU MoBo: nForce 570 SLI chipset GigaByte GA-M57SLI-S4 with F8 (latest) BIOS RAM: 1GB 667MHz noname Software Environment: doesn't matter Problem Description: i386 SMP kernel (2.6.20.7 and latest 2.6.21 snapshot) won't boot giving this error message (root=/dev/sda6 ro reboot=warm apic=debug) CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping 02 Total of 2 processors activated (8851.10 BogoMIPS). Enabling IO-APIC IRQs ..Timer: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ... trying to setup timer (IRQ0) through the 8259A ... failed ... trying to setup timer as Virtual Wire IRQ ... failed ... trying to setup timer as extINT IRQ ... failed :(. Kernel panic - not syncing: IO-APIC + timer doesn't work. Boot with apic=debug Steps to reproduce: compile kernel, try to boot
Created attachment 11259 [details] Miscellaneous PC information gathered from /proc and other utilities The kernel *will* boot with these options: acpi=ht acpi=off acpi=noirq noapic So probably this problem is related to ACPI subsystem.
Looks like a ACPI problem to me when it works with acpi=ht Best would be if you add acpidmp output
Created attachment 11265 [details] ACPI dumps
>Nvidia board detected. Ignoring ACPI timer override. >If you got timer trouble try acpi_use_timer_override this is from the dmesg. So what about boot with acpi_use_timer_override?
Created attachment 11306 [details] dmesg and /proc output with acpi_use_timer_override option > So what about boot with acpi_use_timer_override? This option indeed solved this issue. Nevertheless this has to be fixed in the kernel.
No, this kernel parameter is for some Nvidia NF5 boards that require a timer override, but don't have HPET. I think that's the real problem. :)
No kernel documentation reflects your words, thus you are leaving nForce5 users with no choice but to never run Linux kernel. // I'm sorry, but I find this bugzilla useless and worthless.
The Nforce5 problem is known. It is a unfortunate combination of an BIOS bug in older Nvidia systems and then a change in NF5 that suddenly required the previously buggy part. Also Windows doesn't use this particular part of the ACPI BIOS so most vendors never bothered to fix it. There were some attempts to fix it properly by probing the hardware more aggressively, but they caused too much breakage. Might be reintroduced later. For completeness can you add your lspci output please?
My lspci output can be found in the first attachment ;-) http://bugme.osdl.org/attachment.cgi?id=11259&action=view
Andy, will there be any workaround in the future kernel releases?
Andi, could it be a wrong IO-APIC setup (mode, dest id etc.)? Maybe io-apic dump would help along with boot trace showing APIC IDs...
Andi, Do I understand right, and skip_timer_override was added for NFORCE2 and NFORCE3, and now we appear to not need it on NFORCE5? May be we could change to skip override only on some selected chipsets (e.g. NFORCE2&3) and leave NFORCE5 intact?
Yes, but so far we couldn't figure out the correct PCI IDs for that. I tried asking nvidia, but they didn't answer.
Created attachment 11732 [details] Force acpi_use_timer_override on NFORCE5 chipset Please try if this patch helps... MCP55 PCI Bridge ID is found in pciutils package.
My PC will be functional on Friday only, so, please, wait.
Created attachment 11806 [details] earlyquirk.c rediffed I have rediffed your patch so that it applies cleanly on 2.6.21.5 kernel. And, yes, the problem is now gone. I hope this patch will be merged with 2.6.22 kernel.
These other bug threads may help for those still having issues (who found this thread) http://bugzilla.kernel.org/show_bug.cgi?id=8714 http://bugzilla.kernel.org/show_bug.cgi?id=8219 As of gentoo's 2.6.22-gentoo-r1 #1 SMP compiled Fri Jul 20 2007, I still require acpi_use_timer_override, however all the details are in the later thread.
It's strange that I still don't see any updates on the ACPI side. As for 2.6.22 I still have to use acpi_use_timer_override as a kernel boot option.
Do ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/early-quirks-unification ftp://ftp.firstfloor.org/pub/ak/x86_64/quilt/patches/nvidia-timer-quirk (apply both in this order) fix it?
The first patch in this thread has solved this issue. Andi, I see that you completely purge arch/i386/kernel/acpi/earlyquirk.c and add some new stuff to arch/x86_64/kernel/early-quirks.c How are you patches supposed to work if I run i386 kernel? I will test your patches a bit later.
I'd apply Alexey's patch, but it looks like Andi has bigger plans for early-quirk. Re-assigning to Andi.
Andi, I will retest your patches when at least 2.6.23-rc2 is out.
moving to timers category from ACPI category
This bug doesn't trigger on my PC any longer because a newer GigaByte BIOS (11b), where a working HPET timer was introduced, has fixed this issue.