linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] linux-2.5.69_clear-smi-fix_A1
@ 2003-05-13  0:30 john stultz
  2003-05-13  0:54 ` Dave Hansen
  2003-05-13 14:03 ` Dave Jones
  0 siblings, 2 replies; 4+ messages in thread
From: john stultz @ 2003-05-13  0:30 UTC (permalink / raw)
  To: lkml; +Cc: Andrew Morton, Alan Cox, James

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:





^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] linux-2.5.69_clear-smi-fix_A1
  2003-05-13  0:30 [PATCH] linux-2.5.69_clear-smi-fix_A1 john stultz
@ 2003-05-13  0:54 ` Dave Hansen
  2003-05-13  1:03   ` john stultz
  2003-05-13 14:03 ` Dave Jones
  1 sibling, 1 reply; 4+ messages in thread
From: Dave Hansen @ 2003-05-13  0:54 UTC (permalink / raw)
  To: john stultz; +Cc: lkml, Andrew Morton, Alan Cox, James

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
haveblue@us.ibm.com


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] linux-2.5.69_clear-smi-fix_A1
  2003-05-13  0:54 ` Dave Hansen
@ 2003-05-13  1:03   ` john stultz
  0 siblings, 0 replies; 4+ messages in thread
From: john stultz @ 2003-05-13  1:03 UTC (permalink / raw)
  To: Dave Hansen; +Cc: lkml, Andrew Morton, Alan Cox, James

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] linux-2.5.69_clear-smi-fix_A1
  2003-05-13  0:30 [PATCH] linux-2.5.69_clear-smi-fix_A1 john stultz
  2003-05-13  0:54 ` Dave Hansen
@ 2003-05-13 14:03 ` Dave Jones
  1 sibling, 0 replies; 4+ messages in thread
From: Dave Jones @ 2003-05-13 14:03 UTC (permalink / raw)
  To: john stultz; +Cc: lkml, Andrew Morton, Alan Cox, James

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-05-13 13:51 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-13  0:30 [PATCH] linux-2.5.69_clear-smi-fix_A1 john stultz
2003-05-13  0:54 ` Dave Hansen
2003-05-13  1:03   ` john stultz
2003-05-13 14:03 ` Dave Jones

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).