mirror of https://gitee.com/openkylin/linux.git
2e556b5b32
During testing of a patch to stop having the perf subsytem swallow nmis, it was uncovered that Nehalem boxes were randomly getting unknown nmis when using the perf tool. Moving the ack'ing of the PMI closer to when we get the status allows the hardware to properly re-set the PMU bit signaling another PMI was triggered during the processing of the first PMI. This allows the new logic for dealing with the shortcomings of multiple PMIs to handle the extra NMI by 'eat'ing it later. Now one can wonder why are we getting a second PMI when we disable all the PMUs in the begining of the NMI handler to prevent such a case, for that I do not know. But I know the fix below helps deal with this quirk. Tested on multiple Nehalems where the problem was occuring. With the patch, the code now loops a second time to handle the second PMI (whereas before it was not). Signed-off-by: Don Zickus <dzickus@redhat.com> Cc: peterz@infradead.org Cc: robert.richter@amd.com Cc: gorcunov@gmail.com Cc: fweisbec@gmail.com Cc: ying.huang@intel.com Cc: ming.m.lin@intel.com Cc: eranian@google.com LKML-Reference: <1283454469-1909-2-git-send-email-dzickus@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> |
||
|---|---|---|
| .. | ||
| cpufreq | ||
| mcheck | ||
| mtrr | ||
| .gitignore | ||
| Makefile | ||
| amd.c | ||
| bugs.c | ||
| bugs_64.c | ||
| centaur.c | ||
| common.c | ||
| cpu.h | ||
| cyrix.c | ||
| hypervisor.c | ||
| intel.c | ||
| intel_cacheinfo.c | ||
| mkcapflags.pl | ||
| mshyperv.c | ||
| perf_event.c | ||
| perf_event_amd.c | ||
| perf_event_intel.c | ||
| perf_event_intel_ds.c | ||
| perf_event_intel_lbr.c | ||
| perf_event_p4.c | ||
| perf_event_p6.c | ||
| perfctr-watchdog.c | ||
| powerflags.c | ||
| proc.c | ||
| scattered.c | ||
| sched.c | ||
| topology.c | ||
| transmeta.c | ||
| umc.c | ||
| vmware.c | ||