Bug 438342
| Summary: | Oprofile does not work in R2 or MRG | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | IBM Bug Proxy <bugproxy> | ||||
| Component: | realtime-kernel | Assignee: | Clark Williams <williams> | ||||
| Status: | CLOSED NEXTRELEASE | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | beta | CC: | bhu, iboverma, wcohen, williams | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-06-02 22:32:02 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
IBM Bug Proxy
2008-03-20 13:56:23 UTC
------- Comment From mauery.com 2008-03-25 16:00 EDT------- In all my attempts to get oprofile working with various -rt kernels and various versions of oprofile, I must have messed something up. I just tried again using a fresh install of MRG plus acme's build of oprofile and that combination seems to work fine for me. I am going to close this bug out. *** This bug has been marked as a duplicate of 40996 *** ------- Comment From jstultz.com 2008-03-25 17:06 EDT------- Reopening as we need to track this into MRG. ------- Comment From sripathi.com 2008-03-31 08:00 EDT------- RH has put an updated oprofile rpm in their repos. I installed this rpm (oprofile-0.9.3-16.el5), but I continued to see the same error as before!! I then installed http://userweb.kernel.org/~acme/oprofile-0.9.3-6.acme.x86_64.rpm on the same machine and saw that the errors disappear. So http://userweb.kernel.org/~acme/oprofile-0.9.3-6.acme.x86_64.rpm works, but oprofile-0.9.3-16.el5 doesn't seem to. Ankita, could you please verify this? In case I did something wrong... The difference between the two rpms is that the one that works has a patch that check the /dev/oprofile/ for the various counter directories ([0-9]+). The patched code generates a bit mask based on the counter directories that are available and only puts the events in the available counters. Sripathi, Would you boot our latest kernel with nmi_watchdog=0 and see if the version of oprofile delivered with MRG works? Clark Created attachment 299937 [details]
Patch to make oprofile only use counters that are available
The attached patch was proposed in nov 2006. It didn't get any comments on it
and wasn't pushed into the upstream oprofile. Changes were made in the kernel,
so that this was no longer an apparent problem in the kernel after 2.6.19 (e.g.
unable to replicate problem on 2.6.24.3-50.f8 kernel with watchdog timer). The
RT kernel appears to be doing things differently.
After discussing this with Clark and trying the workaround successfully, I was asked to summarize our results here. - In RHEL-5 oprofile works because the oprofile-kernel piece disables the nmi_watchdog allowing it to access all 4 performance counters (IOW either nmi_watchdog or oprofile can run but not both) - Upstream 2.6.19 and later, I added code that allows both oprofile and nmi_watchdog to run together (at the cost of one perf counter). - Fedora follows upstream and upstream has nmi_watchdog disabled by default, so the oprofile-userspace patch was never needed (unless you enabled nmi_watchdog, then it would be necessary) - kernel-rt follows RHEL-5 and enables the nmi_watchdog by default thus causing this bugzilla (and the need for the oprofile-userspace patch). - testing with nmi_watchdog=1 on the boot commandline failed to show this failure because nmi_watchdog=1 uses IO_APIC for the watchdog which does _not_ use perfcounters. Booting with nmi_watchdog=2 uses the LOCAL_APIC and does use the perfcounters The temporary workaround to avoid using the userspace patch would be to boot the kernel-rt normally and run the following commands to use oprofile # echo 0 > /proc/sys/kernel/nmi_watchdog //disable nmi_watchdog # *oprofile stuff* # opcontrol --deinit //unload oprofile driver module # echo 1 > /proc/sys/kernel/nmi_watchdog //re-enable nmi_watchdog booting with nmi_watchdog=0 is not recommended if you would like to turn the nmi_watchdog on later because 'echo 1 > /proc/sys/kernel/nmi_watchdog' has a bug that prevents turning on the nmi_watchdog for the first time. I think that covers everything. Cheers, Don ------- Comment From mauery.com 2008-04-02 18:23 EDT------- I have verified that the 'echo [01] > /proc/sys/kernel/nmi_watchdog' workaround as described above works with the oprofile-0.9.3-16.el5 package. We'll need to wait for a user-space update to opcontrol for a permanent fix. With a workaround in place, I'm going to drop the severity from urgent to medium Clark We've pushed the RHEL5.2 candidate rpm into the MRG beta repository and will carry that until MRG RT rebases to RHEL5.2 (from RHEL5.1). ------- Comment From sripathi.com 2008-05-27 12:52 EDT------- (In reply to comment #26) > ------- Comment From williams 2008-05-02 15:28 EST------- > We've pushed the RHEL5.2 candidate rpm into the MRG beta repository and will > carry that until MRG RT rebases to RHEL5.2 (from RHEL5.1). I don't see the rpm under http://ftp.redhat.com/pub/redhat/linux/beta/MRG/RHEL-5/. Isn't that the place to find it? I believe that the 5.2 packages got pulled from the beta repository when RHEL5.2 GA'ed. Do we need to put it back? ------- Comment From sripathi.com 2008-05-28 05:48 EDT------- (In reply to comment #28) > ------- Comment From williams 2008-05-27 18:16 EST------- > I believe that the 5.2 packages got pulled from the beta repository when RHEL5.2 > GA'ed. Do we need to put it back? Yes, if MRG is going to be supported on RHEL5.1. I thought it was so. oprofile packages back in the repository, closing ------- Comment From sripathi.com 2008-06-03 02:03 EDT------- Closing on our side as well. |