[PATCH][RFC] P4/Xeon Thermal LVT support

[PATCH][RFC] P4/Xeon Thermal LVT support

[Zwane Mwaikambo]

Hi Dave,
	This patch enables thermal monitoring on P4/Xeon and also installs 
an interrupt handler to take notification of thermal state transitions. 
Its currently untested, so input would be appreciated.

Thanks,
	Zwane

-- 
http://function.linuxpower.ca
		

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Zwane Mwaikambo]

On Wed, 27 Mar 2002, Zwane Mwaikambo wrote:

> Hi Dave,
> 	This patch enables thermal monitoring on P4/Xeon and also installs 
> an interrupt handler to take notification of thermal state transitions. 
> Its currently untested, so input would be appreciated.
> 
> Thanks,
> 	Zwane
> 
> 

argh...

diff -ur linux-2.5-dj-orig/arch/i386/kernel/apic.c linux-2.5.5-dj/arch/i386/kernel/apic.c
--- linux-2.5-dj-orig/arch/i386/kernel/apic.c	Sat Mar 23 21:10:58 2002
+++ linux-2.5.5-dj/arch/i386/kernel/apic.c	Sat Mar 23 20:43:18 2002
@@ -449,6 +449,7 @@
 	unsigned int apic_lvterr;
 	unsigned int apic_tmict;
 	unsigned int apic_tdcr;
+	unsigned int apic_thmr;
 } apic_pm_state;
 
 static void apic_pm_suspend(void *data)
@@ -470,6 +471,7 @@
 	apic_pm_state.apic_lvterr = apic_read(APIC_LVTERR);
 	apic_pm_state.apic_tmict = apic_read(APIC_TMICT);
 	apic_pm_state.apic_tdcr = apic_read(APIC_TDCR);
+	apic_pm_state.apic_thmr = apic_read(APIC_LVTTHMR);
 	__save_flags(flags);
 	__cli();
 	disable_local_APIC();
@@ -498,6 +500,7 @@
 	apic_write(APIC_SPIV, apic_pm_state.apic_spiv);
 	apic_write(APIC_LVT0, apic_pm_state.apic_lvt0);
 	apic_write(APIC_LVT1, apic_pm_state.apic_lvt1);
+	apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
 	apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
 	apic_write(APIC_LVTT, apic_pm_state.apic_lvtt);
 	apic_write(APIC_TDCR, apic_pm_state.apic_tdcr);
diff -ur linux-2.5-dj-orig/arch/i386/kernel/bluesmoke.c linux-2.5.5-dj/arch/i386/kernel/bluesmoke.c
--- linux-2.5-dj-orig/arch/i386/kernel/bluesmoke.c	Sat Mar 23 21:10:58 2002
+++ linux-2.5.5-dj/arch/i386/kernel/bluesmoke.c	Tue Mar 26 22:52:59 2002
@@ -8,6 +8,8 @@
 #include <asm/processor.h> 
 #include <asm/system.h>
 #include <asm/msr.h>
+#include <asm/apic.h>
+#include <asm/hw_irq.h>
 
 #ifdef CONFIG_X86_MCE
 
@@ -16,6 +18,86 @@
 static int banks;
 
 /*
+ *	P4/Xeon Thermal transition interrupt handler
+ */
+
+static void intel_thermal_interrupt(struct pt_regs *regs, long error_code)
+{
+#ifdef CONFIG_X86_LOCAL_APIC
+	u32 l, h;
+	unsigned int cpu = smp_processor_id();
+
+	ack_APIC_irq();
+
+	rdmsr(MSR_IA32_THERM_STATUS, l, h);
+	if (l & 1) {
+		printk(KERN_EMERG "CPU#%d: Temperature above threshold\n", cpu);
+		printk(KERN_EMERG "CPU#%d: Running in modulated clock mode\n", cpu);
+	} else {
+		printk(KERN_INFO "CPU#%d: Temperature/speed normal\n", cpu);
+	}
+#endif
+}
+
+static void unexpected_thermal_interrupt(struct pt_regs * regs, long error_code)
+{	
+	printk(KERN_ERR "CPU#%d: Unexpected LVT TMR interrupt!\n", smp_processor_id());
+}
+
+/*
+ *	Thermal interrupt handler for this CPU setup
+ */
+
+void (*thermal_monitor)(struct pt_regs *, long error_code) = unexpected_thermal_interrupt;
+
+
+/* P4/Xeon Thermal regulation detect and init */
+
+static void __init intel_init_thermal(struct cpuinfo_x86 *c)
+{
+#ifdef CONFIG_X86_LOCAL_APIC
+	u32 l, h;
+	unsigned int cpu = smp_processor_id();
+
+	/* Thermal monitoring */
+	if (!test_bit(X86_FEATURE_ACPI, &c->x86_capability))
+		return;	/* -ENODEV */
+	
+	/* Clock modulation */
+	if (!test_bit(X86_FEATURE_ACC, &c->x86_capability))
+		return;	/* -ENODEV */
+
+	rdmsr(MSR_IA32_MISC_ENABLE, l, h);
+	/* first check if its enabled already, in which case there might
+	 * be some SMM goo which handles it, so we can't even put a handler
+	 * since it might be delivered via SMI already -zwanem.
+	 */
+	if (l & (1<<3)) {
+		printk(KERN_DEBUG "CPU#%d: Thermal monitoring already enabled\n", cpu);
+		return;	/* -EBUSY */
+	}
+	
+	wrmsr(MSR_IA32_MISC_ENABLE, l | (1<<3), h);
+	printk(KERN_INFO "CPU#%d: Thermal monitoring enabled\n", cpu);
+	
+	/* The temperature transition interrupt handler setup */
+	l = THERMAL_APIC_VECTOR;		/* our delivery vector */
+	l |= (APIC_DM_FIXED | APIC_LVT_MASKED);	/* we'll mask till we're ready */
+	apic_write_around(APIC_LVTTHMR, l);
+
+	rdmsr(MSR_IA32_THERM_INTERRUPT, l, h);
+	wrmsr(MSR_IA32_THERM_INTERRUPT, l | 0x3 , h);
+
+	/* ok we're good to go... */
+	thermal_monitor = intel_thermal_interrupt;
+	l = apic_read(APIC_LVTTHMR);
+	apic_write_around(APIC_LVTTHMR, l & ~APIC_LVT_MASKED);
+
+	return;
+#endif
+}
+
+/*
  *	Machine Check Handler For PII/PIII
  */
 
@@ -236,6 +318,9 @@
 	}
 	set_in_cr4(X86_CR4_MCE);
 	printk(KERN_INFO "Intel machine check reporting enabled on CPU#%d.\n", smp_processor_id());
+	
+	intel_init_thermal(c);
+
 	done=1;
 }
 
@@ -317,5 +402,6 @@
 
 #else
 asmlinkage void do_machine_check(struct pt_regs * regs, long error_code) {}
+void thermal_monitor(struct pt_regs * regs, long error_code) {}
 void __init mcheck_init(struct cpuinfo_x86 *c) {}
 #endif
diff -ur linux-2.5-dj-orig/arch/i386/kernel/traps.c linux-2.5.5-dj/arch/i386/kernel/traps.c
--- linux-2.5-dj-orig/arch/i386/kernel/traps.c	Sat Mar 23 21:10:58 2002
+++ linux-2.5.5-dj/arch/i386/kernel/traps.c	Tue Mar 26 22:57:03 2002
@@ -88,7 +88,7 @@
 asmlinkage void alignment_check(void);
 asmlinkage void spurious_interrupt_bug(void);
 asmlinkage void machine_check(void);
-
+asmlinkage void thermal_monitor(void);
 int kstack_depth_to_print = 24;
 
 
@@ -995,8 +995,10 @@
 	set_trap_gate(17,&alignment_check);
 	set_trap_gate(18,&machine_check);
 	set_trap_gate(19,&simd_coprocessor_error);
-
+	
 	set_system_gate(SYSCALL_VECTOR,&system_call);
+	set_intr_gate(THERMAL_APIC_VECTOR, &thermal_monitor);
+
 
 	/*
 	 * default LDT is a single-entry callgate to lcall7 for iBCS
diff -ur linux-2.5-dj-orig/include/asm-i386/apicdef.h linux-2.5.5-dj/include/asm-i386/apicdef.h
--- linux-2.5-dj-orig/include/asm-i386/apicdef.h	Sun Aug 12 20:13:59 2001
+++ linux-2.5.5-dj/include/asm-i386/apicdef.h	Sat Mar 23 22:35:06 2002
@@ -71,6 +71,7 @@
 #define			GET_APIC_DEST_FIELD(x)	(((x)>>24)&0xFF)
 #define			SET_APIC_DEST_FIELD(x)	((x)<<24)
 #define		APIC_LVTT	0x320
+#define		APIC_LVTTHMR	0x330
 #define		APIC_LVTPC	0x340
 #define		APIC_LVT0	0x350
 #define			APIC_LVT_TIMER_BASE_MASK	(0x3<<18)
@@ -280,7 +281,16 @@
 		u32 __reserved_4[3];
 	} lvt_timer;
 
-/*330*/	struct { u32 __reserved[4]; } __reserved_15;
+/*330*/	struct { /* LVT - Thermal Sensor */
+		u32  vector		:  8,
+			delivery_mode	:  3,
+			__reserved_1	:  1,
+			delivery_status	:  1,
+			__reserved_2	:  3,
+			mask		:  1,
+			__reserved_3	: 15;
+		u32 __reserved_4[3];
+	} lvt_thermal;
 
 /*340*/	struct { /* LVT - Performance Counter */
 		u32   vector		:  8,
diff -ur linux-2.5-dj-orig/include/asm-i386/hw_irq.h linux-2.5.5-dj/include/asm-i386/hw_irq.h
--- linux-2.5-dj-orig/include/asm-i386/hw_irq.h	Sat Mar 23 21:09:51 2002
+++ linux-2.5.5-dj/include/asm-i386/hw_irq.h	Tue Mar 26 23:19:56 2002
@@ -56,6 +56,7 @@
  * levels. (0x80 is the syscall vector)
  */
 #define FIRST_DEVICE_VECTOR	0x31
+#define THERMAL_APIC_VECTOR	0x32	/* Thermal monitor local vector */
 #define FIRST_SYSTEM_VECTOR	0xef
 
 extern int irq_vector[NR_IRQS];
diff -ur linux-2.5-dj-orig/include/asm-i386/msr.h linux-2.5.5-dj/include/asm-i386/msr.h
--- linux-2.5-dj-orig/include/asm-i386/msr.h	Sat Mar 23 21:11:06 2002
+++ linux-2.5.5-dj/include/asm-i386/msr.h	Sat Mar 23 18:35:47 2002
@@ -60,6 +60,11 @@
 #define MSR_P6_EVNTSEL0		0x186
 #define MSR_P6_EVNTSEL1		0x187
 
+#define MSR_IA32_THERM_CONTROL		0x19a
+#define MSR_IA32_THERM_INTERRUPT	0x19b
+#define MSR_IA32_THERM_STATUS		0x19c
+#define MSR_IA32_MISC_ENABLE		0x1a0
+
 #define MSR_IA32_DEBUGCTLMSR		0x1d9
 #define MSR_IA32_LASTBRANCHFROMIP	0x1db
 #define MSR_IA32_LASTBRANCHTOIP		0x1dc

-- 
http://function.linuxpower.ca
		

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Dave Jones]

On Wed, Mar 27, 2002 at 08:04:37AM +0200, Zwane Mwaikambo wrote:

 > +	rdmsr(MSR_IA32_THERM_STATUS, l, h);
 > +	if (l & 1) {
 > +		printk(KERN_EMERG "CPU#%d: Temperature above threshold\n", cpu);
 > +		printk(KERN_EMERG "CPU#%d: Running in modulated clock mode\n", cpu);
 > +	} else {
 > +		printk(KERN_INFO "CPU#%d: Temperature/speed normal\n", cpu);
 > +	}

This chunk probably wants to be rate-limited to avoid flooding the
same message over and over.

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Zwane Mwaikambo]

On Wed, 27 Mar 2002, Dave Jones wrote:

> On Wed, Mar 27, 2002 at 08:04:37AM +0200, Zwane Mwaikambo wrote:
> 
>  > +	rdmsr(MSR_IA32_THERM_STATUS, l, h);
>  > +	if (l & 1) {
>  > +		printk(KERN_EMERG "CPU#%d: Temperature above threshold\n", cpu);
>  > +		printk(KERN_EMERG "CPU#%d: Running in modulated clock mode\n", cpu);
>  > +	} else {
>  > +		printk(KERN_INFO "CPU#%d: Temperature/speed normal\n", cpu);
>  > +	}
> 
> This chunk probably wants to be rate-limited to avoid flooding the
> same message over and over.

That shouldn't be a problem since the interrupt only occurs on thermal 
transition, ie when you hit over the threshold or hit below. Therefore we 
shouldn't be fluctuating since the clock modulation will be in effect and 
the temperature will drop. However i can't be 100% certain.

	Zwane

-- 
http://function.linuxpower.ca
		

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Dave Jones]

On Wed, Mar 27, 2002 at 01:36:04PM +0200, Zwane Mwaikambo wrote:

 > That shouldn't be a problem since the interrupt only occurs on thermal 
 > transition, ie when you hit over the threshold or hit below. Therefore we 
 > shouldn't be fluctuating since the clock modulation will be in effect and 
 > the temperature will drop. However i can't be 100% certain.

Ok, I'll drop it into -dj2 and see if any P4 owning people scream 8)

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Zwane Mwaikambo]

On Wed, 27 Mar 2002, Dave Jones wrote:

> Ok, I'll drop it into -dj2 and see if any P4 owning people scream 8)

Cool, perhaps i should have CC'd Mikael Pettersson since he seems to do 
quite a bit of APIC stuff as well as owning a P4 board.

Cheers,
	Zwane

-- 
http://function.linuxpower.ca
		

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Maciej W. Rozycki]

On Wed, 27 Mar 2002, Zwane Mwaikambo wrote:

>  #define FIRST_DEVICE_VECTOR	0x31
> +#define THERMAL_APIC_VECTOR	0x32	/* Thermal monitor local vector */
>  #define FIRST_SYSTEM_VECTOR	0xef

 You certainly want to select a different vector.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Zwane Mwaikambo]

On Wed, 27 Mar 2002, Maciej W. Rozycki wrote:

> On Wed, 27 Mar 2002, Zwane Mwaikambo wrote:
> 
> >  #define FIRST_DEVICE_VECTOR	0x31
> > +#define THERMAL_APIC_VECTOR	0x32	/* Thermal monitor local vector */
> >  #define FIRST_SYSTEM_VECTOR	0xef
> 
>  You certainly want to select a different vector.

Whats wrong with that vector? I tried to follow the guidelines as 
specified in hw_irq.h and opted to go for the lower priority ones, or 
is the vector not serviceable due to its range?

Thanks,
	Zwane

-- 
http://function.linuxpower.ca
		

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Maciej W. Rozycki]

On Wed, 27 Mar 2002, Zwane Mwaikambo wrote:

> > >  #define FIRST_DEVICE_VECTOR	0x31
> > > +#define THERMAL_APIC_VECTOR	0x32	/* Thermal monitor local vector */
> > >  #define FIRST_SYSTEM_VECTOR	0xef
> > 
> >  You certainly want to select a different vector.
> 
> Whats wrong with that vector? I tried to follow the guidelines as 
> specified in hw_irq.h and opted to go for the lower priority ones, or 
> is the vector not serviceable due to its range?

 You can't use a vector that is in the range assigned to I/O APIC
interrupts (i.e.  0x31 - 0xee).  Otherwise you'll get an overlap when the
vector gets assigned to an ordinary IRQ line.  Also you probably want a
high-priority interrupt as the condition is serious, if not critical --
system failures, such as bus exceptions, machine check faults, parity
errors, power failures, etc. demand a high priority service. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Zwane Mwaikambo]

On Wed, 27 Mar 2002, Maciej W. Rozycki wrote:

>  You can't use a vector that is in the range assigned to I/O APIC
> interrupts (i.e.  0x31 - 0xee).  Otherwise you'll get an overlap when the
> vector gets assigned to an ordinary IRQ line.  Also you probably want a

Thanks, i'll fix that.

> high-priority interrupt as the condition is serious, if not critical --
> system failures, such as bus exceptions, machine check faults, parity
> errors, power failures, etc. demand a high priority service. 

Its really not that critical, its more informational, the interrupt 
handler in fact only displays a warning, by which time the hardware is 
already handling the condition.

Thanks for the input.

	Zwane

-- 
http://function.linuxpower.ca
		

[PATCH][RFC] P4/Xeon Thermal LVT support (take 2)

[Zwane Mwaikambo]

Vector has been changed as suggested by Maciej.

Regards,
	Zwane

diff -ur linux-2.5-dj-orig/arch/i386/kernel/apic.c linux-2.5-dj-work/arch/i386/kernel/apic.c
--- linux-2.5-dj-orig/arch/i386/kernel/apic.c	Wed Mar 27 17:52:15 2002
+++ linux-2.5-dj-work/arch/i386/kernel/apic.c	Wed Mar 27 17:56:05 2002
@@ -449,6 +449,7 @@
 	unsigned int apic_lvterr;
 	unsigned int apic_tmict;
 	unsigned int apic_tdcr;
+	unsigned int apic_thmr;
 } apic_pm_state;
 
 static void apic_pm_suspend(void *data)
@@ -470,6 +471,7 @@
 	apic_pm_state.apic_lvterr = apic_read(APIC_LVTERR);
 	apic_pm_state.apic_tmict = apic_read(APIC_TMICT);
 	apic_pm_state.apic_tdcr = apic_read(APIC_TDCR);
+	apic_pm_state.apic_thmr = apic_read(APIC_LVTTHMR);
 	__save_flags(flags);
 	__cli();
 	disable_local_APIC();
@@ -498,6 +500,7 @@
 	apic_write(APIC_SPIV, apic_pm_state.apic_spiv);
 	apic_write(APIC_LVT0, apic_pm_state.apic_lvt0);
 	apic_write(APIC_LVT1, apic_pm_state.apic_lvt1);
+	apic_write(APIC_LVTTHMR, apic_pm_state.apic_thmr);
 	apic_write(APIC_LVTPC, apic_pm_state.apic_lvtpc);
 	apic_write(APIC_LVTT, apic_pm_state.apic_lvtt);
 	apic_write(APIC_TDCR, apic_pm_state.apic_tdcr);
diff -ur linux-2.5-dj-orig/arch/i386/kernel/bluesmoke.c linux-2.5-dj-work/arch/i386/kernel/bluesmoke.c
--- linux-2.5-dj-orig/arch/i386/kernel/bluesmoke.c	Wed Mar 27 17:52:15 2002
+++ linux-2.5-dj-work/arch/i386/kernel/bluesmoke.c	Wed Mar 27 17:56:05 2002
@@ -8,6 +8,8 @@
 #include <asm/processor.h> 
 #include <asm/system.h>
 #include <asm/msr.h>
+#include <asm/apic.h>
+#include <asm/hw_irq.h>
 
 #ifdef CONFIG_X86_MCE
 
@@ -16,6 +18,86 @@
 static int banks;
 
 /*
+ *	P4/Xeon Thermal transition interrupt handler
+ */
+
+static void intel_thermal_interrupt(struct pt_regs *regs, long error_code)
+{
+#ifdef CONFIG_X86_LOCAL_APIC
+	u32 l, h;
+	unsigned int cpu = smp_processor_id();
+
+	ack_APIC_irq();
+
+	rdmsr(MSR_IA32_THERM_STATUS, l, h);
+	if (l & 1) {
+		printk(KERN_EMERG "CPU#%d: Temperature above threshold\n", cpu);
+		printk(KERN_EMERG "CPU#%d: Running in modulated clock mode\n", cpu);
+	} else {
+		printk(KERN_INFO "CPU#%d: Temperature/speed normal\n", cpu);
+	}
+#endif
+}
+
+static void unexpected_thermal_interrupt(struct pt_regs * regs, long error_code)
+{	
+	printk(KERN_ERR "CPU#%d: Unexpected LVT TMR interrupt!\n", smp_processor_id());
+}
+
+/*
+ *	Thermal interrupt handler for this CPU setup
+ */
+
+void (*thermal_monitor)(struct pt_regs *, long error_code) = unexpected_thermal_interrupt;
+
+
+/* P4/Xeon Thermal regulation detect and init */
+
+static void __init intel_init_thermal(struct cpuinfo_x86 *c)
+{
+#ifdef CONFIG_X86_LOCAL_APIC
+	u32 l, h;
+	unsigned int cpu = smp_processor_id();
+
+	/* Thermal monitoring */
+	if (!test_bit(X86_FEATURE_ACPI, &c->x86_capability))
+		return;	/* -ENODEV */
+	
+	/* Clock modulation */
+	if (!test_bit(X86_FEATURE_ACC, &c->x86_capability))
+		return;	/* -ENODEV */
+
+	rdmsr(MSR_IA32_MISC_ENABLE, l, h);
+	/* first check if its enabled already, in which case there might
+	 * be some SMM goo which handles it, so we can't even put a handler
+	 * since it might be delivered via SMI already -zwanem.
+	 */
+	if (l & (1<<3)) {
+		printk(KERN_DEBUG "CPU#%d: Thermal monitoring already enabled\n", cpu);
+		return;	/* -EBUSY */
+	}
+	
+	wrmsr(MSR_IA32_MISC_ENABLE, l | (1<<3), h);
+	printk(KERN_INFO "CPU#%d: Thermal monitoring enabled\n", cpu);
+	
+	/* The temperature transition interrupt handler setup */
+	l = THERMAL_APIC_VECTOR;		/* our delivery vector */
+	l |= (APIC_DM_FIXED | APIC_LVT_MASKED);	/* we'll mask till we're ready */
+	apic_write_around(APIC_LVTTHMR, l);
+
+	rdmsr(MSR_IA32_THERM_INTERRUPT, l, h);
+	wrmsr(MSR_IA32_THERM_INTERRUPT, l | 0x3 , h);
+
+	/* ok we're good to go... */
+	thermal_monitor = intel_thermal_interrupt;
+	l = apic_read(APIC_LVTTHMR);
+	apic_write_around(APIC_LVTTHMR, l & ~APIC_LVT_MASKED);
+
+	return;
+#endif
+}
+
+/*
  *	Machine Check Handler For PII/PIII
  */
 
@@ -236,6 +318,9 @@
 	}
 	set_in_cr4(X86_CR4_MCE);
 	printk(KERN_INFO "Intel machine check reporting enabled on CPU#%d.\n", smp_processor_id());
+	
+	intel_init_thermal(c);
+
 	done=1;
 }
 
@@ -317,5 +402,6 @@
 
 #else
 asmlinkage void do_machine_check(struct pt_regs * regs, long error_code) {}
+void thermal_monitor(struct pt_regs * regs, long error_code) {}
 void __init mcheck_init(struct cpuinfo_x86 *c) {}
 #endif
diff -ur linux-2.5-dj-orig/arch/i386/kernel/traps.c linux-2.5-dj-work/arch/i386/kernel/traps.c
--- linux-2.5-dj-orig/arch/i386/kernel/traps.c	Wed Mar 27 17:52:15 2002
+++ linux-2.5-dj-work/arch/i386/kernel/traps.c	Wed Mar 27 17:56:05 2002
@@ -88,7 +88,7 @@
 asmlinkage void alignment_check(void);
 asmlinkage void spurious_interrupt_bug(void);
 asmlinkage void machine_check(void);
-
+asmlinkage void thermal_monitor(void);
 int kstack_depth_to_print = 24;
 
 
@@ -995,8 +995,10 @@
 	set_trap_gate(17,&alignment_check);
 	set_trap_gate(18,&machine_check);
 	set_trap_gate(19,&simd_coprocessor_error);
-
+	
 	set_system_gate(SYSCALL_VECTOR,&system_call);
+	set_intr_gate(THERMAL_APIC_VECTOR, &thermal_monitor);
+
 
 	/*
 	 * default LDT is a single-entry callgate to lcall7 for iBCS
diff -ur linux-2.5-dj-orig/include/asm-i386/apicdef.h linux-2.5-dj-work/include/asm-i386/apicdef.h
--- linux-2.5-dj-orig/include/asm-i386/apicdef.h	Sun Aug 12 20:13:59 2001
+++ linux-2.5-dj-work/include/asm-i386/apicdef.h	Wed Mar 27 17:56:05 2002
@@ -71,6 +71,7 @@
 #define			GET_APIC_DEST_FIELD(x)	(((x)>>24)&0xFF)
 #define			SET_APIC_DEST_FIELD(x)	((x)<<24)
 #define		APIC_LVTT	0x320
+#define		APIC_LVTTHMR	0x330
 #define		APIC_LVTPC	0x340
 #define		APIC_LVT0	0x350
 #define			APIC_LVT_TIMER_BASE_MASK	(0x3<<18)
@@ -280,7 +281,16 @@
 		u32 __reserved_4[3];
 	} lvt_timer;
 
-/*330*/	struct { u32 __reserved[4]; } __reserved_15;
+/*330*/	struct { /* LVT - Thermal Sensor */
+		u32  vector		:  8,
+			delivery_mode	:  3,
+			__reserved_1	:  1,
+			delivery_status	:  1,
+			__reserved_2	:  3,
+			mask		:  1,
+			__reserved_3	: 15;
+		u32 __reserved_4[3];
+	} lvt_thermal;
 
 /*340*/	struct { /* LVT - Performance Counter */
 		u32   vector		:  8,
diff -ur linux-2.5-dj-orig/include/asm-i386/hw_irq.h linux-2.5-dj-work/include/asm-i386/hw_irq.h
--- linux-2.5-dj-orig/include/asm-i386/hw_irq.h	Wed Mar 27 17:35:40 2002
+++ linux-2.5-dj-work/include/asm-i386/hw_irq.h	Wed Mar 27 17:58:58 2002
@@ -43,6 +43,7 @@
 #define RESCHEDULE_VECTOR	0xfc
 #define CALL_FUNCTION_VECTOR	0xfb
 
+#define THERMAL_APIC_VECTOR	0xf0
 /*
  * Local APIC timer IRQ vector is on a different priority level,
  * to work around the 'lost local interrupt if more than 2 IRQ
diff -ur linux-2.5-dj-orig/include/asm-i386/msr.h linux-2.5-dj-work/include/asm-i386/msr.h
--- linux-2.5-dj-orig/include/asm-i386/msr.h	Wed Mar 27 17:52:23 2002
+++ linux-2.5-dj-work/include/asm-i386/msr.h	Wed Mar 27 17:56:05 2002
@@ -60,6 +60,11 @@
 #define MSR_P6_EVNTSEL0		0x186
 #define MSR_P6_EVNTSEL1		0x187
 
+#define MSR_IA32_THERM_CONTROL		0x19a
+#define MSR_IA32_THERM_INTERRUPT	0x19b
+#define MSR_IA32_THERM_STATUS		0x19c
+#define MSR_IA32_MISC_ENABLE		0x1a0
+
 #define MSR_IA32_DEBUGCTLMSR		0x1d9
 #define MSR_IA32_LASTBRANCHFROMIP	0x1db
 #define MSR_IA32_LASTBRANCHTOIP		0x1dc

-- 
http://function.linuxpower.ca
		

Re: [PATCH][RFC] P4/Xeon Thermal LVT support (take 2)

[Brian Gerst]

Zwane Mwaikambo wrote:
> Vector has been changed as suggested by Maciej.
> 
> Regards,
> 	Zwane

You are missing the asm stub for the interrupt handler.  You can't just 
call C code directly from the interrupt vector.  Look in i8259.c where 
the stubs are for the other APIC interrupts.

-- 

						Brian Gerst

Re: [PATCH][RFC] P4/Xeon Thermal LVT support (take 2)

[Zwane Mwaikambo]

On Wed, 27 Mar 2002, Brian Gerst wrote:

> You are missing the asm stub for the interrupt handler.  You can't just 
> call C code directly from the interrupt vector.  Look in i8259.c where 
> the stubs are for the other APIC interrupts.

hmm, i thought the traps.c stuff was sufficient. Thanks i'll check that 
out.

	Zwane

-- 
http://function.linuxpower.ca
		

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Maciej W. Rozycki]

On Wed, 27 Mar 2002, Zwane Mwaikambo wrote:

> > high-priority interrupt as the condition is serious, if not critical --
> > system failures, such as bus exceptions, machine check faults, parity
> > errors, power failures, etc. demand a high priority service. 
> 
> Its really not that critical, its more informational, the interrupt 
> handler in fact only displays a warning, by which time the hardware is 
> already handling the condition.

 How can't it be critical?  Your system is overheating.  It is about to
fail -- depending on the configuration, it'll either crash or be shut down
by hardware (consider fire in the server room as well).  Either way the
condition should be caught ASAP, for proper steps to be taken by the OS
and/or the operator.  Otherwise it might have no second chance to get
reported and the system will die silently -- you'll not know the reason
until you get at the console (or its remains).  It may be too late then. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Zwane Mwaikambo]

On Wed, 27 Mar 2002, Maciej W. Rozycki wrote:

>  How can't it be critical?  Your system is overheating.  It is about to
> fail -- depending on the configuration, it'll either crash or be shut down
> by hardware (consider fire in the server room as well).  Either way the
> condition should be caught ASAP, for proper steps to be taken by the OS
> and/or the operator.  Otherwise it might have no second chance to get
> reported and the system will die silently -- you'll not know the reason
> until you get at the console (or its remains).  It may be too late then. 

I didn't mean to say that the condition was not critical, i meant that the 
interrupt generated is used for notification purposes, and in its current 
state the interrupt handler only provides information rather than taking 
measures due to the condition. The condition in this case is handled 
automatically by the hardware and we just receive notification via an 
interrupt getting triggered. However i have taken your suggestion and 
moved the vector.

Cheers,
	Zwane

 -- 
http://function.linuxpower.ca
		

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Alan Cox]

> > handler in fact only displays a warning, by which time the hardware is 
> > already handling the condition.
> 
>  How can't it be critical?  Your system is overheating.  It is about to
> fail -- depending on the configuration, it'll either crash or be shut down

Neither. It will drop to a much lower clock speed. You can set it to overheat
and blow up but thats a mostly undocumented mtrr 8) The default behaviour is
to throttle back hard

Alan

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Mike Dresser]

On Wed, 27 Mar 2002, Alan Cox wrote:

> Neither. It will drop to a much lower clock speed. You can set it to overheat
> and blow up but thats a mostly undocumented mtrr 8) The default behaviour is

Will Tom's Hardware Guide film this for us, if we ask politely? :)

mike

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Joel Jaeggli]

On Wed, 27 Mar 2002, Mike Dresser wrote:

> On Wed, 27 Mar 2002, Alan Cox wrote:
> 
> > Neither. It will drop to a much lower clock speed. You can set it to overheat
> > and blow up but thats a mostly undocumented mtrr 8) The default behaviour is
> 
> Will Tom's Hardware Guide film this for us, if we ask politely? :)

they've already filmed one not catching fire...
 
> mike
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli	      Academic User Services   joelja@darkwing.uoregon.edu    
--    PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E      --
The accumulation of all powers, legislative, executive, and judiciary, in 
the same hands, whether of one, a few, or many, and whether hereditary, 
selfappointed, or elective, may justly be pronounced the very definition of
tyranny. - James Madison, Federalist Papers 47 -  Feb 1, 1788

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Mike Dresser]

On Wed, 27 Mar 2002, Joel Jaeggli wrote:

> On Wed, 27 Mar 2002, Mike Dresser wrote:
>
> > On Wed, 27 Mar 2002, Alan Cox wrote:
> >
> > > Neither. It will drop to a much lower clock speed. You can set it to overheat
> > > and blow up but thats a mostly undocumented mtrr 8) The default behaviour is
> >
> > Will Tom's Hardware Guide film this for us, if we ask politely? :)
>
> they've already filmed one not catching fire...

It's the undocumented mtrr that I'm interested in!

mike

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Alan Cox]

> > > Will Tom's Hardware Guide film this for us, if we ask politely? :)
> > they've already filmed one not catching fire...
> It's the undocumented mtrr that I'm interested in!

You'll have to do your own research

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Maciej W. Rozycki]

On Wed, 27 Mar 2002, Alan Cox wrote:

> >  How can't it be critical?  Your system is overheating.  It is about to
> > fail -- depending on the configuration, it'll either crash or be shut down
> 
> Neither. It will drop to a much lower clock speed. You can set it to overheat
> and blow up but thats a mostly undocumented mtrr 8) The default behaviour is
> to throttle back hard

 Depending on the reason of an overheat condition this may circumvent the
problem or not.  As I already stated you may have fire in the room (and
not all computer rooms seem to have automatic extinguishing systems). 
Hardware failures are not to be treated lightly. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Francois Romieu]

Maciej W. Rozycki <macro@ds2.pg.gda.pl> :
[...]
>  Depending on the reason of an overheat condition this may circumvent the
> problem or not.  As I already stated you may have fire in the room (and
> not all computer rooms seem to have automatic extinguishing systems). 
> Hardware failures are not to be treated lightly. 

Yes, brave CPU burns its last cycles and commits suicide in a desperate try 
to save the room machine. If it can save the World at the same time, it's
ready for Hollywood imho :o)

-- 
Ueimor

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Pavel Machek]

Hi!

> > >  How can't it be critical?  Your system is overheating.  It is about to
> > > fail -- depending on the configuration, it'll either crash or be shut down
> > 
> > Neither. It will drop to a much lower clock speed. You can set it to overheat
> > and blow up but thats a mostly undocumented mtrr 8) The default behaviour is
> > to throttle back hard
> 
>  Depending on the reason of an overheat condition this may circumvent the
> problem or not.  As I already stated you may have fire in the room (and
> not all computer rooms seem to have automatic extinguishing systems). 
> Hardware failures are not to be treated lightly. 

Overheat is not neccessarily hardware failure.

You see, I have a notebook. I put pen in it to stop the fan. Hardware
is pretty much okay, but, well, pen does not allow fan to spin.

What's the best behaviour? Throttle is okay.

I take the same notebook, let it compile kernel, put it into my bed,
and cover it. What should happen? Throttle is okay. I'll get warm bed
and compiled kernel.

Is there something better you propose notebook to do.

And now, you have fire at server room. All cpus throtle, then are
burn. Does it matter if they throttled? No.

And now, you have your must-be-running server at university. Its fan
fails. What do you want it to do? Throttle is the best thing. (It
might deliver mail slightly slower, but it can probably handle load
during the night so I can get there).

So it seems to me throttle is always right answer.
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Maciej W. Rozycki]

On Sat, 30 Mar 2002, Pavel Machek wrote:

> Overheat is not neccessarily hardware failure.

 It is the failing condition.  It need not be a result of a hardware
failure. 

> You see, I have a notebook. I put pen in it to stop the fan. Hardware
> is pretty much okay, but, well, pen does not allow fan to spin.

 A fan blockage is a hardware failure as well.  Regardless of the reason. 
It certainly isn't a software failure. 

> What's the best behaviour? Throttle is okay.

 Sure that is a way to protect the CPU but it may fail if the reason is
not heat emitted by the CPU.

> And now, you have fire at server room. All cpus throtle, then are
> burn. Does it matter if they throttled? No.

 But it matters if an operator got warned before (that is what I remarked
originally).  The operator may be in a distant location.  Or he may be
nearby and be able to act to stop the fire once he gets a message. 

> So it seems to me throttle is always right answer.

 Sure it is a way to try to recover, if hardware provides it, but it's
completely orthogonal to the question whether to report a thermal problem
or not and at which priority.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Zwane Mwaikambo]

On Wed, 27 Mar 2002, Maciej W. Rozycki wrote:

>  You can't use a vector that is in the range assigned to I/O APIC
> interrupts (i.e.  0x31 - 0xee).  Otherwise you'll get an overlap when the
> vector gets assigned to an ordinary IRQ line.  Also you probably want a
> high-priority interrupt as the condition is serious, if not critical --
> system failures, such as bus exceptions, machine check faults, parity
> errors, power failures, etc. demand a high priority service. 

Would f0 be ok? But i see its assigned for "future linux use"

Thanks,
	Zwane

-- 
http://function.linuxpower.ca
		

Re: [PATCH][RFC] P4/Xeon Thermal LVT support

[Maciej W. Rozycki]

On Wed, 27 Mar 2002, Zwane Mwaikambo wrote:

> Would f0 be ok? But i see its assigned for "future linux use"

 Well I see:

Vectors 0xf0-0xfa are free (reserved for future Linux use).

and your code definitely qualifies here. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +