Most recent kernel where this bug did *NOT* occur: not known, I've tested only
188.8.131.52 release and the aforementioned kernel version.
Distribution: doesn't matter - a kernel bug
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 (184.108.40.206 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:
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]
>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
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 ;-)
Andy, will there be any workaround in the future kernel releases?
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...
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]
I have rediffed your patch so that it applies cleanly on 220.127.116.11 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)
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.
(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.