I did rm the '/root/.oprofile/daemonrc' but I still cannot make it run.
The parameter is like the following:
crypt14:~# opcontrol --start-daemon --xen=/boot/xen-syms-3.4.2
/usr/local/bin/opcontrol: line 1391: echo: write error: Invalid argument
/usr/local/bin/opcontrol: line 1171: echo: write error: Invalid argument
oprofiled: no events specified.
Usage: oprofiled [OPTION...]
Is it correct how Oprofile been used in timer mode?
On Mon, Sep 13, 2010 at 4:15 PM, William Cohen <wcohen@...> wrote:
> On 09/13/2010 04:01 PM, K L wrote:
>> Hi William,
>> Thanks for the reply. If there is no way to set event, how can I make
>> the opcontrol daemon running in timer mode. I have read the following
>> 4.3. OProfile in timer interrupt mode
>> This section applies to 2.6 kernels and above only.
>> In 2.6 kernels on CPUs without OProfile support for the hardware
>> performance counters, the driver falls back to using the timer
>> interrupt for profiling. Like the RTC mode in 2.4 kernels, this is not
>> able to profile code that has interrupts disabled. Note that there are
>> no configuration parameters for setting this, unlike the RTC and
>> hardware performance counter setup.
>> You can force use of the timer interrupt by using the timer=1 module
>> parameter (or oprofile.timer=1 on the boot command line if OProfile is
>> Normally, I built oprofile from the source code by typing './configure
>> --with-kernel-support' and 'make;make install'. I can find no module
>> been compiled. Where should I put the module parameters like
>> 'oprofile.timer=1'? Would you like inform me how to make it run in
>> timer mode?
>> Many thanks,
> In your case you don't need to include the 'oprofile.timer=1' when loading the oprofile kernel module. The oprofile kernel module already determines that it should use the fallback timer mode because it can't identify the processor. However, you might rm the /root/.oprofile/daemonrc which probably has some --event setting in it. opcontrol might be confused about those old setting.
> --with-kernel-support assumes using a new enough kernel that includes the oprofile support. As a result, it doesn't build the kernel module because none is needed.
>> On Mon, Sep 13, 2010 at 10:33 AM, William Cohen <wcohen@...> wrote:
>>> On 09/10/2010 10:22 PM, K L wrote:
>>>> Dear all,
>>>> I have a new HP proliant 320 G6 machine that installed with Debian
>>>> Lenny. I download the oprofile-0.9.5 and have it successfully compiled
>>>> and installed. But I cannot use events and make it run. Every time I
>>>> run opcontrol I see the using timer interrupt
>>>> crypt14:~# opcontrol --start-daemon --event=GLOBAL_POWER_EVENTS:1000000:1:1
>>>> /usr/local/bin/opcontrol: line 367: timer: command not found
>>>> You cannot specify any performance counter events
>>>> because OProfile is in timer mode.
>>>> I did my homework by reading through the mailinglist archive but seems
>>>> it has something to do with the CPU type. But I do not find a solution
>>>> even I try modify the code that not checking the cpu type. I also
>>>> enabled all APIC and disabled the power management functions in the
>>>> machine BIOS.
>>>> The machine has 4 core, 2 hyperthreading on each core. The detailed
>>>> info is listed as follows:
>>>> processor : 7
>>>> vendor_id : GenuineIntel
>>>> cpu family : 6
>>>> model : 44
>>>> model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
>>>> stepping : 2
>>>> cpu MHz : 2400.082
>>>> cache size : 12288 KB
>>>> physical id : 1
>>>> siblings : 8
>>>> core id : 9
>>>> cpu cores : 4
>>>> apicid : 51
>>>> initial apicid : 51
>>>> fpu : yes
>>>> fpu_exception : yes
>>>> cpuid level : 11
>>>> wp : yes
>>>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>>>> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
>>>> syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
>>>> rep_good pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr dca sse4_1
>>>> sse4_2 popcnt lahf_lm ida
>>>> bogomips : 4800.15
>>>> clflush size : 64
>>>> cache_alignment : 64
>>>> address sizes : 40 bits physical, 48 bits virtual
>>>> power management:
>>>> Is there anybody who also have experience with the HP proliant
>>>> machine? I could provide detailed information. Any comments are
>>>> greatly appreciated.
>>> Hi Jeff,
>>> It looks like the particular kernel being used on the machine doesn't recognize processor and using the fallback timer mode. The git repository for upstream linux kernel doesn't have an entry for this particular processor in the ppro_init() function:
>>> There needs to be an entry in pprop_init() for the kernel to recognize the processor. It looks to be a westmere based processor.
>>> Start uncovering the many advantages of virtual appliances
>>> and start using them to simplify application deployment and
>>> accelerate your shift to cloud computing
>>> oprofile-list mailing list