All,
I've been having problems with ACPI on a box here in our lab. Some of
our more recent hardware requires that SMIs are routed through the
IOAPIC, thus when we clear_IO_APIC() at boot time, we clear the BIOS
initialized SMI pin. This basically clobbers the SMI so we can then
never make the transition into ACPI mode.
This patch simply reads the apic entry in clear_IO_APIC to make sure the
delivery_mode isn't dest_SMI. If it is, we leave the apic entry alone
and return.
With this patch, the box boots and SMIs function properly.
Please consider for inclusion.
thanks
-john
Changes since _A0:
o yanked printk
o locked the io_apic_read calls to insure atomicity
diff -Nru a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
--- a/arch/i386/kernel/io_apic.c Mon May 12 17:16:06 2003
+++ b/arch/i386/kernel/io_apic.c Mon May 12 17:16:06 2003
@@ -219,6 +219,14 @@
{
struct IO_APIC_route_entry entry;
unsigned long flags;
+
+ /* Check delivery_mode to be sure we're not clearing an SMI pin */
+ spin_lock_irqsave(&ioapic_lock, flags);
+ *(((int*)&entry) + 0) = io_apic_read(apic, 0x10 + 2 * pin);
+ *(((int*)&entry) + 1) = io_apic_read(apic, 0x11 + 2 * pin);
+ spin_unlock_irqrestore(&ioapic_lock, flags);
+ if (entry.delivery_mode == dest_SMI)
+ return;
/*
* Disable it in the IO-APIC irq-routing table:
john stultz wrote:
> All,
> I've been having problems with ACPI on a box here in our lab. Some of
> our more recent hardware requires that SMIs are routed through the
> IOAPIC, thus when we clear_IO_APIC() at boot time, we clear the BIOS
> initialized SMI pin. This basically clobbers the SMI so we can then
> never make the transition into ACPI mode.
>
> This patch simply reads the apic entry in clear_IO_APIC to make sure the
> delivery_mode isn't dest_SMI. If it is, we leave the apic entry alone
> and return.
>
> With this patch, the box boots and SMIs function properly.
So, without the patch, what happens? Does the thing just completely
freeze when it tries to turn ACPI on? Does the machine _require_ that
you use ACPI?
--
Dave Hansen
[email protected]
On Mon, 2003-05-12 at 17:54, Dave Hansen wrote:
> john stultz wrote:
> > I've been having problems with ACPI on a box here in our lab. Some of
> > our more recent hardware requires that SMIs are routed through the
> > IOAPIC, thus when we clear_IO_APIC() at boot time, we clear the BIOS
> > initialized SMI pin. This basically clobbers the SMI so we can then
> > never make the transition into ACPI mode.
> >
> > This patch simply reads the apic entry in clear_IO_APIC to make sure the
> > delivery_mode isn't dest_SMI. If it is, we leave the apic entry alone
> > and return.
> >
> > With this patch, the box boots and SMIs function properly.
>
> So, without the patch, what happens? Does the thing just completely
> freeze when it tries to turn ACPI on? Does the machine _require_ that
> you use ACPI?
When trying to boot w/ ACPI the transition fails and the box hobbles
along to different degrees. Normally the interrupt routing is bad and a
scsi or network card fails to init.
Without ACPI the system boots fine. SMIs are still clobbered, but
they're less critical.
But really, ACPI (and SMIs) should "just work". ;)
thanks
-john
On Mon, May 12, 2003 at 05:30:03PM -0700, john stultz wrote:
> I've been having problems with ACPI on a box here in our lab. Some of
> our more recent hardware requires that SMIs are routed through the
> IOAPIC, thus when we clear_IO_APIC() at boot time, we clear the BIOS
> initialized SMI pin. This basically clobbers the SMI so we can then
> never make the transition into ACPI mode.
>
> This patch simply reads the apic entry in clear_IO_APIC to make sure the
> delivery_mode isn't dest_SMI. If it is, we leave the apic entry alone
> and return.
>
> With this patch, the box boots and SMIs function properly.
There's a whole bunch of 'ACPI buggers up interrupt routing' bugs
in bugzilla right now, I wonder if this could help out with those.
Dave