[RFC][PATCH] linux-2.5.69_clear-smi-fix_A0

[RFC][PATCH] linux-2.5.69_clear-smi-fix_A0

[john stultz]

All,
	I've been having problems with ACPI on a box here in our lab, it ends
up that when we clear_IO_APIC() at boot time, we clear the SMI pin that
is setup by the BIOS. This basically clobbers the SMI and we can then
never make the transition into ACPI mode. 

I'm not sure if this is the right solution, but I figured I'd post it
and take the flamage if I'm just being dumb. Basically in
clear_IO_APIC_pin, I read the apic entry 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 appear to function properly.

Let me know if you have any thoughts or suggestions.

thanks
-john


diff -Nru a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
--- a/arch/i386/kernel/io_apic.c	Tue May  6 14:46:58 2003
+++ b/arch/i386/kernel/io_apic.c	Tue May  6 14:46:58 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 */
+	*(((int*)&entry) + 0) = io_apic_read(apic, 0x10 + 2 * pin);
+	*(((int*)&entry) + 1) = io_apic_read(apic, 0x11 + 2 * pin);
+	if (entry.delivery_mode == dest_SMI){
+		printk(KERN_INFO "apic %i pin %i is an SMI pin!\n", apic, pin);
+		return;
+	}
 
 	/*
 	 * Disable it in the IO-APIC irq-routing table:

Re: [RFC][PATCH] linux-2.5.69_clear-smi-fix_A0

[James Cleverdon]

John,

That looks reasonable to me.  The one possible catch would be for systems so 
old they don't do SMI -- 386s and 486s, I imagine.  If this code doesn't barf 
on them when CONFIG_IO_APIC is turned on, then it should be fine (minus the 
printk).

(I believe there was at least one such system, the Intel Xpress box.  It 
contained a 486 and seperate APIC chips.)

		James

On Tuesday 06 May 2003 02:58 pm, john stultz wrote:
> All,
> 	I've been having problems with ACPI on a box here in our lab, it ends
> up that when we clear_IO_APIC() at boot time, we clear the SMI pin that
> is setup by the BIOS. This basically clobbers the SMI and we can then
> never make the transition into ACPI mode.
>
> I'm not sure if this is the right solution, but I figured I'd post it
> and take the flamage if I'm just being dumb. Basically in
> clear_IO_APIC_pin, I read the apic entry 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 appear to function properly.
>
> Let me know if you have any thoughts or suggestions.
>
> thanks
> -john
>
>
> diff -Nru a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
> --- a/arch/i386/kernel/io_apic.c	Tue May  6 14:46:58 2003
> +++ b/arch/i386/kernel/io_apic.c	Tue May  6 14:46:58 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 */
> +	*(((int*)&entry) + 0) = io_apic_read(apic, 0x10 + 2 * pin);
> +	*(((int*)&entry) + 1) = io_apic_read(apic, 0x11 + 2 * pin);
> +	if (entry.delivery_mode == dest_SMI){
> +		printk(KERN_INFO "apic %i pin %i is an SMI pin!\n", apic, pin);
> +		return;
> +	}
>
>  	/*
>  	 * Disable it in the IO-APIC irq-routing table:

-- 
James Cleverdon
IBM xSeries Linux Solutions
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot com

Re: [RFC][PATCH] linux-2.5.69_clear-smi-fix_A0

[Alan Cox]

On Mer, 2003-05-07 at 15:54, James Cleverdon wrote:
> (I believe there was at least one such system, the Intel Xpress box.  It 
> contained a 486 and seperate APIC chips.)

There are a very very small number with external APIC setups. If I
remember rightly these have a unique APIC version (1 ?) so we can
tell them

Re: [RFC][PATCH] linux-2.5.69_clear-smi-fix_A0

[Zwane Mwaikambo]

On Wed, 7 May 2003, James Cleverdon wrote:

> John,
> 
> That looks reasonable to me.  The one possible catch would be for systems so 
> old they don't do SMI -- 386s and 486s, I imagine.  If this code doesn't barf 
> on them when CONFIG_IO_APIC is turned on, then it should be fine (minus the 
> printk).
> 
> (I believe there was at least one such system, the Intel Xpress box.  It 
> contained a 486 and seperate APIC chips.)

Referring to this?

Intel MultiProcessor Specification v1.4
    Virtual Wire compatibility mode.
OEM ID: INTEL    Product ID: XXPRESS      APIC at: 0xFEE00000
Processor #0 5:2 APIC version 16
Processor #3 5:2 APIC version 16
Processor #4 5:2 APIC version 16
Unknown bustype XPRESS - ignoring
I/O APIC #14 Version 17 at 0xFEC00000.
I/O APIC #13 Version 17 at 0xFFE7F800.
Enabling APIC mode:  Flat.  Using 2 I/O APICs
Processors: 3

John's check should be safe as it doesn't touch hardware anyway.

	Zwane
-- 
function.linuxpower.ca