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
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
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
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
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
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
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: [email protected], PGP key available +
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
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: [email protected], PGP key available +
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
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
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: [email protected], PGP key available +
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
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
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: [email protected], PGP key available +
> > 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
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
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 [email protected]
> 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 [email protected]
-- 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
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
> > > 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
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
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
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: [email protected], PGP key available +
Maciej W. Rozycki <[email protected]> :
[...]
> 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
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
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: [email protected], PGP key available +