- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi.
I have been used the perf counters but there is a strange behavior. When the PMC or fixed counter reaches its overflow situation the interrupt is triggered but just once . After the handler's execution, I have tryied to rearm the counter with the same overflow value but unfortunelly I can't issue this handler again. I'm sure that the overflow flags was zeroed and the overflow bit at global status register is raising but that handler never is called again.
Any clue ?
Thanks.
I have been used the perf counters but there is a strange behavior. When the PMC or fixed counter reaches its overflow situation the interrupt is triggered but just once . After the handler's execution, I have tryied to rearm the counter with the same overflow value but unfortunelly I can't issue this handler again. I'm sure that the overflow flags was zeroed and the overflow bit at global status register is raising but that handler never is called again.
Any clue ?
Thanks.
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - kanobarreto
Hi ....
Yes , there is a reason.. I'm working on a specifc hardware. Vtune won't work on it. The processor is from Nehalem family. Other interrupts are running perfectly. The PMI handler is the only one with that issue. It can't be rearmed. Is really necessary reset APIC ? My concern is that approach will brake other stuffs.
Hello,
Are you setting up the tool for Windows or Linux or some other OS?
If you are using Linux, maybe you would like to read through the the Open Source VDK (VTune Development Kit) code that is part of the Linux VTune distribution.
To get to the root of the problem that you are facing, we need to get a bit deeper into how you are trying to set up the interrupt handler, are you using a NMI or are you programming via the APIC? or are you using some other mechanism?
Basically, the problem that you are facing is that the end-of-interrupt protocol is not being followed. You need to re-enable the interrupt mechanism as well as re-enabling the counters (clear the overflow control register, re-arm the counter, etc. which you have already done).
-bhanu
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - kanobarreto
Hi.
I have been used the perf counters but there is a strange behavior. When the PMC or fixed counter reaches its overflow situation the interrupt is triggered but just once . After the handler's execution, I have tryied to rearm the counter with the same overflow value but unfortunelly I can't issue this handler again. I'm sure that the overflow flags was zeroed and the overflow bit at global status register is raising but that handler never is called again.
Any clue ?
Thanks.
I have been used the perf counters but there is a strange behavior. When the PMC or fixed counter reaches its overflow situation the interrupt is triggered but just once . After the handler's execution, I have tryied to rearm the counter with the same overflow value but unfortunelly I can't issue this handler again. I'm sure that the overflow flags was zeroed and the overflow bit at global status register is raising but that handler never is called again.
Any clue ?
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - kanobarreto
Hi.
I have been used the perf counters but there is a strange behavior. When the PMC or fixed counter reaches its overflow situation the interrupt is triggered but just once . After the handler's execution, I have tryied to rearm the counter with the same overflow value but unfortunelly I can't issue this handler again. I'm sure that the overflow flags was zeroed and the overflow bit at global status register is raising but that handler never is called again.
Any clue ?
Thanks.
I have been used the perf counters but there is a strange behavior. When the PMC or fixed counter reaches its overflow situation the interrupt is triggered but just once . After the handler's execution, I have tryied to rearm the counter with the same overflow value but unfortunelly I can't issue this handler again. I'm sure that the overflow flags was zeroed and the overflow bit at global status register is raising but that handler never is called again.
Any clue ?
Thanks.
I will reiterate David Levinthal's question as well. Is there a reason that you are not using VTune or PTU?
What processor are youworking on? Core, Core 2 or Core i7?
In addition to the reset of the overflow flags, the re-arming of the counter, the APIC needs to be reset as well; i.e. make sure that the interrupt is acknowledged and the End-of-Interrupt protocol is followed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Bhanu Shankar (Intel)
I will reiterate David Levinthal's question as well. Is there a reason that you are not using VTune or PTU?
What processor are youworking on? Core, Core 2 or Core i7?
In addition to the reset of the overflow flags, the re-arming of the counter, the APIC needs to be reset as well; i.e. make sure that the interrupt is acknowledged and the End-of-Interrupt protocol is followed.
Hi ....
Yes , there is a reason.. I'm working on a specifc hardware. Vtune won't work on it. The processor is from Nehalem family. Other interrupts are running perfectly. The PMI handler is the only one with that issue. It can't be rearmed. Is really necessary reset APIC ? My concern is that approach will brake other stuffs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - kanobarreto
Hi ....
Yes , there is a reason.. I'm working on a specifc hardware. Vtune won't work on it. The processor is from Nehalem family. Other interrupts are running perfectly. The PMI handler is the only one with that issue. It can't be rearmed. Is really necessary reset APIC ? My concern is that approach will brake other stuffs.
Hello,
Are you setting up the tool for Windows or Linux or some other OS?
If you are using Linux, maybe you would like to read through the the Open Source VDK (VTune Development Kit) code that is part of the Linux VTune distribution.
To get to the root of the problem that you are facing, we need to get a bit deeper into how you are trying to set up the interrupt handler, are you using a NMI or are you programming via the APIC? or are you using some other mechanism?
Basically, the problem that you are facing is that the end-of-interrupt protocol is not being followed. You need to re-enable the interrupt mechanism as well as re-enabling the counters (clear the overflow control register, re-arm the counter, etc. which you have already done).
-bhanu
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - kanobarreto
Hi.
I have been used the perf counters but there is a strange behavior. When the PMC or fixed counter reaches its overflow situation the interrupt is triggered but just once . After the handler's execution, I have tryied to rearm the counter with the same overflow value but unfortunelly I can't issue this handler again. I'm sure that the overflow flags was zeroed and the overflow bit at global status register is raising but that handler never is called again.
Any clue ?
Thanks.
I have been used the perf counters but there is a strange behavior. When the PMC or fixed counter reaches its overflow situation the interrupt is triggered but just once . After the handler's execution, I have tryied to rearm the counter with the same overflow value but unfortunelly I can't issue this handler again. I'm sure that the overflow flags was zeroed and the overflow bit at global status register is raising but that handler never is called again.
Any clue ?
Thanks.
Intel perf tools (SEP/PTU/VTune) should work on all Core i3, core i5, core i7, xeon 5500 etc systems, assuming you are running a supported OS. For non supported OS's, embedded systems running proprietary OS's, etc...this is not perhaps the best choice of mechanisms to get help from us
:-)
since proprietary information is likely needed from you, for us to provide any assistance.
You really should contact your Intel representative so we can establish the required direct communications.
d

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page