This appears to be a bios bug, when booting without acpi=off I get 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 set up timer (IRQ0) through the 8252A ... failed ... trying to set up timer as Virtual Wire IRQ ... failed ... trying to set up timer as ExtINT IRQ ... failed :(
Created attachment 10182 [details] output of acpidump
Created attachment 10183 [details] output of dmesg
Created attachment 10184 [details] output of /proc/interrupts
Created attachment 10185 [details] output of lipci -vvx
Is this a new bug in 2.6.20-rc or is it also present in older kernels like 2.6.19?
It's present in all the kernels I've got on hand, including 2.6.18 and 2.6.17.
is this an nvidia chipset? if so, please make sure it's got the latest BIOS it might also be worth reporting this to nvidia, there are cases where the details of the PITs connection are misreported by the BIOS so a newer one might already correct this i wonder if the acpi_skip_timer_override magic could be tweaked to help here is why i mention all this
I am on leave until Mon 29th Jan. For any urgent matters, please contact Richard Stewart in the Aberdeen Office. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7651.32"> <TITLE>Out of Office AutoReply: [Bug 7884] fails to setup IO-APIC on KN9-Ultra unless using acpi=off</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=2>I am on leave until Mon 29th Jan.</FONT> </P> <P><FONT SIZE=2>For any urgent matters, please contact Richard Stewart in the Aberdeen Office.</FONT> </P> </BODY> </HTML>
Yup, it's an NVidia chipset, but the bios is at 1.6 which is the latest on the Abit website. I've had a dig around and there is a 1.7 on the taiwan ftp server and a 1.8 in beta at the minute, so I might try the 1.7 and see if it makes any differece.
> Nvidia board detected. Ignoring ACPI timer override. > If you got timer trouble try acpi_use_timer_override So what happens with you boot with "acpi_use_timer_override"? Also, does the system boot in ACPI mode with "noapic"? Though it isn't related to the the timer issue, the attached /proc/interrupts with "acpi=off" looks strange: 217: 15 24183 PCI-MSI-edge eth1 218: 2 1264 PCI-MSI-edge eth1 219: 1 1307 PCI-MSI-edge eth1 You might consider using pci=nomsi for now.
Hi, Tred using acpi_use_timer_override instead of acpi=off and the system failed to bootwith the same symptoms as the riginal bug report. noapic works, the system boots as mentioned previously. Also, having used pci=nomsi results in CPU0 CPU1 0: 72042337 770 IO-APIC-edge timer 1: 335 1 IO-APIC-edge i8042 2: 0 0 XT-PIC-XT cascade 5: 2 1 IO-APIC-fasteoi ohci1394, libata 6: 4 1 IO-APIC-edge floppy 8: 0 1 IO-APIC-edge rtc 10: 6054 1 IO-APIC-fasteoi ohci_hcd:usb1, libata, HDA Intel 11: 25106659 1 IO-APIC-fasteoi libata, ehci_hcd:usb2, eth1, nvidia 12: 3984 2 IO-APIC-edge i8042 14: 343 1 IO-APIC-edge ide0 NMI: 0 0 LOC: 72043779 72043792 ERR: 0 MIS: 0 which looks a bit healthier.
> acpi_use_timer_override Hmmm, I had hoped that would address this issue. Please double check the spelling to make sure the option was recognized. For the case where you successfully boot using just "noapic" please attach the full dmesg and paste a copy of /proc/interrupts. Also, please attach the output from acpidump
Yep, checked the aspeeling and did it again, with exactly the same results. the full dmesg, interrupts and acpidump are up at the top of the thread, unless you want a set from another boot config?
ah, didn't notice the dmesg -- thanks. For the case where you successfully boot using just "noapic" please attach the full dmesg and paste a copy of /proc/interrupts.
Created attachment 10215 [details] /proc/interrupts in the noapic boot /proc/interrupts when the system is booted using noapic
Created attachment 10216 [details] dmesg in the noapic case dmesg when the system is booted using noapic
Updated the system to bios 1.7 ( the latest non-beta release ), no change in behaviour.
Bingo. Latest bios V1.8 was released today, the changelog says increased linux compatibility and the issue is now gone. I'm still not clear on why I get three interrupts assigned to an ethernet interface, but that's a different issue I guess ! Cheers, Eamonn
> Latest bios V1.8 was released today, > the changelog says increased linux > compatibility and the issue is now gone. Hmmm, lets see if we can find out what changed... Running the new BIOS, please attach the output from acpidump, as well as a copy of dmesg -s64000 and paste /proc/interrupts. I think the pci=nomsi was unrelated to the issue and you can probably stop using that and eth1 will simply consume 3 MSI vectors.
Created attachment 11033 [details] dmesg after bios upgrade
Created attachment 11034 [details] acpidump after bios update
Created attachment 11035 [details] interrupts after bios update
Attachements added. The only other change was moving to the 2.6.20 release. I also have the nvidia kernel module installed, but that shouldn't skew these results too much, yes?
Thanks for the info. From the dmesg(comment #3) we can't find the error info(comment #1). From the info(comment #16,#17) we can know that the system can work well when booted with option "noapic". Will you please upload the dmesg and /proc/interrupts using the follwong boot option? 1. acpi=off debug 2. acpi=off debug noapic 3. debug > Created an attachment (id=10183) [details] > output of dmesg >
Hi, This problem was fixed in February with a bios update. The dumps earlier in the thread show the failing state, the later dumps are from the fixed state. On Thu, 2007-08-30 at 22:42 -0700, bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=7884 > > > > > > ------- Comment #24 from yakui.zhao@intel.com 2007-08-30 22:42 ------- > Thanks for the info. > From the dmesg(comment #3) we can't find the error info(comment #1). > From the info(comment #16,#17) we can know that the system can work well > when booted with option "noapic". > Will you please upload the dmesg and /proc/interrupts using the follwong boot > option? > 1. acpi=off debug > 2. acpi=off debug noapic > 3. debug > > > > Created an attachment (id=10183) > --> (http://bugzilla.kernel.org/attachment.cgi?id=10183&action=view) > [details] > > output of dmesg > > > >
*** Bug 8238 has been marked as a duplicate of this bug. ***
Issue can be resolved via bios upgrade. mark this bug as wontfix then.