https://bugzilla.novell.com/show_bug.cgi?id=558740 https://bugzilla.novell.com/show_bug.cgi?id=558740#c79 Jiri Slaby <jslaby@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |amb@jb.man.ac.uk --- Comment #79 from Jiri Slaby <jslaby@novell.com> 2011-01-12 10:58:56 UTC --- (In reply to comment #78)
I can certainly file a bug for the interference of ACPI with VME interrupts. The reason I haven't is because it is hard to provide sufficient evidence without assuming a knowledge of the Tundra VME-PCI Bridge chip.
Why? There seems to be only ACPI IRQ routing broken... It is definitely a good idea to file a separate bug for that one (with the information I'm asking below).
we have also to disable APIC in addition to ACPI in order for VME interrupts to be received.
What happens if you enable ACPI and APIC in the BIOS and pass acpi=noirq to the kernel? And if that doesn't help, try to add noapic too.
We disable ACPI/APIC both in the BIOS and in the kernel ("belt and braces"). It doesn't matter which method we use, either or both produces the required state - VME interrupts are received correctly.
I understand, but I want to know whether the dump in the comment#76 was taken when ACPI in the _BIOS_ was disabled. I'm asking because the BIOS still reports that the ACPI base address is available (and correct). And it's not -- that's the IDE bug you are describing here.
If APIC/ACPI are enabled both in the BIOS and in the kernel, VME interrupts, generated correctly by the VME bridge chip are lost and not received by the processor. I believe this is due to a software fault in the Linux kernel.
(Or broken ACPI IRQ routing tables.) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.