[PATCH] oprofile add Pentium Mobile support

[PATCH] oprofile add Pentium Mobile support

[Philippe Elie]

Hi Andrew, all

apply cleanly to 2.6.3-rc2


From: Will Cohen <wcohen@redhat.com>

Add oprofile support for Pentium Mobile (P6 core). Pentium Mobile needs
to unmask LVPTC vector, since it doesn't hurt other P6 core based cpus
we do it unconditionally for all these.

This patch require userspace tools >= 0.8 (only in sourceforge cvs currently)


regards,
Phil


diff -uprN -X /home/phe/dontdiff-2.6.0 linux-temp/arch/i386/oprofile/nmi_int.c linux-2.5/arch/i386/oprofile/nmi_int.c
--- linux-temp/arch/i386/oprofile/nmi_int.c	2004-02-12 22:00:59.000000000 +0000
+++ linux-2.5/arch/i386/oprofile/nmi_int.c	2004-02-12 22:27:31.000000000 +0000
@@ -335,7 +335,9 @@ static int __init ppro_init(void)
 	if (cpu_model > 0xd)
 		return 0;
 
-	if (cpu_model > 5) {
+	if (cpu_model == 9) {
+		nmi_ops.cpu_type = "i386/p6_mobile";
+	} else if (cpu_model > 5) {
 		nmi_ops.cpu_type = "i386/piii";
 	} else if (cpu_model > 2) {
 		nmi_ops.cpu_type = "i386/pii";
diff -uprN -X /home/phe/dontdiff-2.6.0 linux-temp/arch/i386/oprofile/op_model_ppro.c linux-2.5/arch/i386/oprofile/op_model_ppro.c
--- linux-temp/arch/i386/oprofile/op_model_ppro.c	2004-02-12 22:00:59.000000000 +0000
+++ linux-2.5/arch/i386/oprofile/op_model_ppro.c	2004-02-12 22:27:31.000000000 +0000
@@ -13,6 +13,7 @@
 #include <linux/oprofile.h>
 #include <asm/ptrace.h>
 #include <asm/msr.h>
+#include <asm/apic.h>
  
 #include "op_x86_model.h"
 #include "op_counter.h"
@@ -101,6 +102,10 @@ static int ppro_check_ctrs(unsigned int 
 		}
 	}
 
+	/* Only P6 based Pentium M need to re-unmask the apic vector but it
+	 * doesn't hurt other P6 variant */
+	apic_write(APIC_LVTPC, apic_read(APIC_LVTPC) & ~APIC_LVT_MASKED);
+
 	/* We can't work out if we really handled an interrupt. We
 	 * might have caught a *second* counter just after overflowing
 	 * the interrupt for this counter then arrives

Re: [PATCH] oprofile add Pentium Mobile support

[Mikael Pettersson]

Philippe Elie writes:
 > From: Will Cohen <wcohen@redhat.com>
 > 
 > Add oprofile support for Pentium Mobile (P6 core). Pentium Mobile needs
 > to unmask LVPTC vector, since it doesn't hurt other P6 core based cpus
 > we do it unconditionally for all these.

[Patch talking about the Pentium-M.]

I can find no support in Intel's documentation (IA32 Volume 3,
25366813.pdf) that Pentium-M:s need to unmask LVTPC.

How certain are you of this? Is this an undocumented hardware
quirk? If it is documented, please indicate where.

It's my theory that P4 added the auto-masking to help PEBS
buffer overflow situations, but since P-M doesn't have PEBS,
they shouldn't have had to change this on P-M as well.
OTOH, it's certainly possible they changed it by accident.

One way of testing this would be to run a P-M with
nmi_watchdog=2. If the NMI counter keeps ticking, then
LVTPC does not need unmasking.

/Mikael

Re: [PATCH] oprofile add Pentium Mobile support

[Will Cohen]

Mikael Pettersson wrote:
> Philippe Elie writes:
>  > From: Will Cohen <wcohen@redhat.com>
>  > 
>  > Add oprofile support for Pentium Mobile (P6 core). Pentium Mobile needs
>  > to unmask LVPTC vector, since it doesn't hurt other P6 core based cpus
>  > we do it unconditionally for all these.
> 
> [Patch talking about the Pentium-M.]
> 
> I can find no support in Intel's documentation (IA32 Volume 3,
> 25366813.pdf) that Pentium-M:s need to unmask LVTPC.
> 
> How certain are you of this? Is this an undocumented hardware
> quirk? If it is documented, please indicate where.

I have tested it on a Pentium M machine. Without the unmask LVTPC the 
nmi handler collected precisely one interrupt. With the LVTPC unmask the 
OProfile data collection worked normally.

> It's my theory that P4 added the auto-masking to help PEBS
> buffer overflow situations, but since P-M doesn't have PEBS,
> they shouldn't have had to change this on P-M as well.
> OTOH, it's certainly possible they changed it by accident.

My theory is that the Pentium M uses same bus interface and local apic 
as the Pentium M. Thus, the Pentium M shares the Pentium 4 need to 
unmask LVTPC.

> One way of testing this would be to run a P-M with
> nmi_watchdog=2. If the NMI counter keeps ticking, then
> LVTPC does not need unmasking.

Yes, I tested the nmi watchdog and it currently does not work on the 
Pentium M. It doesn't get the later interrupts and states it is stuck.


-Will

Re: [PATCH] oprofile add Pentium Mobile support

[Mikael Pettersson]

Will Cohen writes:
 > Mikael Pettersson wrote:
 > > Philippe Elie writes:
 > >  > From: Will Cohen <wcohen@redhat.com>
 > >  > 
 > >  > Add oprofile support for Pentium Mobile (P6 core). Pentium Mobile needs
 > >  > to unmask LVPTC vector, since it doesn't hurt other P6 core based cpus
 > >  > we do it unconditionally for all these.
 > > 
 > > [Patch talking about the Pentium-M.]
 > > 
 > > I can find no support in Intel's documentation (IA32 Volume 3,
 > > 25366813.pdf) that Pentium-M:s need to unmask LVTPC.
 > > 
 > > How certain are you of this? Is this an undocumented hardware
 > > quirk? If it is documented, please indicate where.
 > 
 > I have tested it on a Pentium M machine. Without the unmask LVTPC the 
 > nmi handler collected precisely one interrupt. With the LVTPC unmask the 
 > OProfile data collection worked normally.
 > 
 > > It's my theory that P4 added the auto-masking to help PEBS
 > > buffer overflow situations, but since P-M doesn't have PEBS,
 > > they shouldn't have had to change this on P-M as well.
 > > OTOH, it's certainly possible they changed it by accident.
 > 
 > My theory is that the Pentium M uses same bus interface and local apic 
 > as the Pentium M. Thus, the Pentium M shares the Pentium 4 need to 
 > unmask LVTPC.

Sounds reasonable and is consistent with other P-M vs P6 changes.

 > > One way of testing this would be to run a P-M with
 > > nmi_watchdog=2. If the NMI counter keeps ticking, then
 > > LVTPC does not need unmasking.
 > 
 > Yes, I tested the nmi watchdog and it currently does not work on the 
 > Pentium M. It doesn't get the later interrupts and states it is stuck.

That confirms the "undocumented HW quirk" theory. Thanks. I'll fix
the (in-kernel) NMI watchdog and (out-of-kernel) perfctr drivers.

/Mikael