projects / thirdparty / kernel / stable-queue.git / blame
| Commit | Line | Data |
|---|---|---|
| 1bbce966 GKH |
1 | From stable-bounces@linux.kernel.org Wed Feb 21 21:14:47 2007 |
| 2 | From: Livio Soares <livio@eecg.toronto.edu> | |
| 3 | Date: Thu, 22 Feb 2007 16:13:17 +1100 | |
| 4 | Subject: POWERPC: Fix performance monitor exception | |
| 5 | To: stable@kernel.org | |
| 6 | Message-ID: <17885.9837.44671.2038@cargo.ozlabs.ibm.com> | |
| 7 | ||
| 8 | ||
| 9 | From: Livio Soares <livio@eecg.toronto.edu> | |
| 10 | ||
| 11 | To the issue: some point during 2.6.20 development, Paul Mackerras | |
| 12 | introduced the "lazy IRQ disabling" patch (very cool work, BTW). | |
| 13 | In that patch, the performance monitor unit exception was marked as | |
| 14 | "maskable", in the sense that if interrupts were soft-disabled, that | |
| 15 | exception could be ignored. This broke my PowerPC profiling code. | |
| 16 | The symptom that I see is that a varying number of interrupts | |
| 17 | (from 0 to $n$, typically closer to 0) get delivered, when, in | |
| 18 | reality, it should always be very close to $n$. | |
| 19 | ||
| 20 | The issue stems from the way masking is being done. Masking in | |
| 21 | this fashion seems to work well with the decrementer and external | |
| 22 | interrupts, because they are raised again until "really" handled. | |
| 23 | For the PMU, however, this does not apply (at least on my Xserver | |
| 24 | machine with a 970FX processor). If the PMU exception is not handled, | |
| 25 | it will _not_ be re-raised (at least on my machine). The documentation | |
| 26 | states that the PMXE bit in MMCR0 is set to 0 when the PMU exception | |
| 27 | is raised. However, software must re-set the bit to re-enable PMU | |
| 28 | exceptions. If the exception is ignored (as currently) not only is | |
| 29 | that interrupt lost, but because software does not re-set PMXE, the | |
| 30 | PMU registers are "frozen" forever. | |
| 31 | ||
| 32 | [This patch means that performance monitor exceptions are taken and | |
| 33 | handled even if irqs are off, as long as some other interrupt hasn't | |
| 34 | come along and caused interrupts to be hard-disabled. In this sense | |
| 35 | the PMU exception becomes like an NMI. The oprofile code for most | |
| 36 | powerpc processors does nothing that is unsafe in an NMI context, but | |
| 37 | the Cell oprofile code does a spin_lock_irqsave. However, that turns | |
| 38 | out to be OK because Cell doesn't actually use the performance | |
| 39 | monitor exception; performance monitor interrupts come in as a | |
| 40 | regular interrupt on Cell, so will be disabled when irqs are off. | |
| 41 | -- paulus.] | |
| 42 | ||
| 43 | From: Livio Soares <livio@eecg.toronto.edu> | |
| 44 | Signed-off-by: Paul Mackerras <paulus@samba.org> | |
| 45 | Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> | |
| 46 | ||
| 47 | --- | |
| 48 | arch/powerpc/kernel/head_64.S | 2 +- | |
| 49 | 1 file changed, 1 insertion(+), 1 deletion(-) | |
| 50 | ||
| 51 | --- linux-2.6.20.1.orig/arch/powerpc/kernel/head_64.S | |
| 52 | +++ linux-2.6.20.1/arch/powerpc/kernel/head_64.S | |
| 53 | @@ -613,7 +613,7 @@ system_call_pSeries: | |
| 54 | /*** pSeries interrupt support ***/ | |
| 55 | ||
| 56 | /* moved from 0xf00 */ | |
| 57 | - MASKABLE_EXCEPTION_PSERIES(., performance_monitor) | |
| 58 | + STD_EXCEPTION_PSERIES(., performance_monitor) | |
| 59 | ||
| 60 | /* | |
| 61 | * An interrupt came in while soft-disabled; clear EE in SRR1, |