diff options
| author | Tejun Heo <tj@kernel.org> | 2011-03-04 19:09:02 +0100 |
|---|---|---|
| committer | Tejun Heo <tj@kernel.org> | 2011-03-04 19:09:02 +0100 |
| commit | e83a46bbb1d4c03defd733a64b727632a40059ad (patch) | |
| tree | c4bc4822b2d3af1bf38095f531adc0a2aac054a5 /arch/x86/kernel/cpu/perf_event_p4.c | |
| parent | da527770007fce8e4541947d47918248286da875 (diff) | |
| parent | fd51469fb68b987032e46297e0a4fe9020063c20 (diff) | |
| download | op-kernel-dev-e83a46bbb1d4c03defd733a64b727632a40059ad.zip op-kernel-dev-e83a46bbb1d4c03defd733a64b727632a40059ad.tar.gz | |
Merge branch 'for-linus' of ../linux-2.6-block into block-for-2.6.39/core
This merge creates two set of conflicts. One is simple context
conflicts caused by removal of throtl_scheduled_delayed_work() in
for-linus and removal of throtl_shutdown_timer_wq() in
for-2.6.39/core.
The other is caused by commit 255bb490c8 (block: blk-flush shouldn't
call directly into q->request_fn() __blk_run_queue()) in for-linus
crashing with FLUSH reimplementation in for-2.6.39/core. The conflict
isn't trivial but the resolution is straight-forward.
* __blk_run_queue() calls in flush_end_io() and flush_data_end_io()
should be called with @force_kblockd set to %true.
* elv_insert() in blk_kick_flush() should use
%ELEVATOR_INSERT_REQUEUE.
Both changes are to avoid invoking ->request_fn() directly from
request completion path and closely match the changes in the commit
255bb490c8.
Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'arch/x86/kernel/cpu/perf_event_p4.c')
| -rw-r--r-- | arch/x86/kernel/cpu/perf_event_p4.c | 11 |
1 files changed, 8 insertions, 3 deletions
diff --git a/arch/x86/kernel/cpu/perf_event_p4.c b/arch/x86/kernel/cpu/perf_event_p4.c index f7a0993..ff751a9 100644 --- a/arch/x86/kernel/cpu/perf_event_p4.c +++ b/arch/x86/kernel/cpu/perf_event_p4.c @@ -770,9 +770,14 @@ static inline int p4_pmu_clear_cccr_ovf(struct hw_perf_event *hwc) return 1; } - /* it might be unflagged overflow */ - rdmsrl(hwc->event_base + hwc->idx, v); - if (!(v & ARCH_P4_CNTRVAL_MASK)) + /* + * In some circumstances the overflow might issue an NMI but did + * not set P4_CCCR_OVF bit. Because a counter holds a negative value + * we simply check for high bit being set, if it's cleared it means + * the counter has reached zero value and continued counting before + * real NMI signal was received: + */ + if (!(v & ARCH_P4_UNFLAGGED_BIT)) return 1; return 0; |
