On Tue, 03 Feb 2004 at 11:05 +0000, Alex Tsariounov wrote:
Sorry mail accidentally send ... ignore my last mail
> On Tue, Feb 03, 2004 at 12:46:46PM -0500, William Cohen wrote:
> > Alex Tsariounov wrote:
> > > flags : fpu vme de pse tsc msr pae mce cx8 sep
> > > mtrr pge mca cmov pat pse36 mmx fxsr sse
> > > bogomips : 1675.26
> > This /proc/cpuinfo could explain the problem. Use of the performance
> > monitoring hardware requires the "apic" flag in the "flags" listing.
> Yes, this laptop has never been able to use the perf counter
> to APIC to NMI path for sampling, even in 2.4 where it had
> to use the RTC.
> At one point I thought all laptop/mobiles were like that
> until I found one laptop that has a functional APIC path.
> > > Kernel command line: BOOT_IMAGE=2.6.1 ro root=306
> > > psmouse.psmouse_proto=bare
> > > Local APIC disabled by BIOS -- reenabling.
> > > Could not enable APIC!
> > > Initializing CPU#0
> > It looks like the Local APIC is totally missing on this processor. I
> > think using performance monitoring hardware on this machine is a lost cause.
> Yes perf counters are, but my question was why there are no
> samples for the 2.6 timer_int mechanism. If I run 2.4, the
> oprofile module uses the RTC and things are fine.
let me clarify my answer in another thread: it's a bug in 2.6 driver,
the sequence of event is as follow
int __init oprofile_arch_init(struct oprofile_operations ** ops)
int ret = -ENODEV;
ret = nmi_init(ops);
if (ret < 0)
ret = nmi_timer_init(ops);
ret = nmi_int(ops); do proper check and can fails but nmi_timer_int()
never fail so the caller can't fall back to "normal" timer_int, the only
way you have is to remove CONFIG_IO_APIC (which is anyway not required
for CONFIG_LOCAL_APIC), it's annoying since you can't use the same
.config on a SMP and a UP box and get a working Oprofie with 2.6 kernel
> > >Is there a way to get the raw buffers out somehow,
> > >translated into ascii preferably?
> > You can use "opcontrol --start --verbose" to get additional information
> > in the /var/lib/oprofile/oprofile.log.
> I posted that log in my original mail though. There was no
> more information there that what I posted. It would be very
> useful to have an ASCII output that just dumps all buffer
> information while running (for the daemon now) so one could
> pour through that for debugging purposes. For example, my
> project does something like that with the --ascii-trace
current cvs use a more fine grained --verbose= options, I'm unsure
it it'll sufficient for your need.
> > >Yes, in this case the RTC was better since you could set the
> > >sample rate. Does the timer_int have the benefit of seeing
> > >into interrupt context?
> > Do you mean getting samples from areas of code with the interrupt is
> > masked? The timer_int is just a regular interrupt, so it isn't going to
> > get samples in areas where interrupts are masked.
> Oh, I see, in that case it's the same as the RTC and
> processing while interrupts are disabled is invisible. Now,
> the 2.4 oprofile module could use the RTC, does the 2.6
> version not have that capability?
No, the prefered source are in this order PMC, nmi_timer_int through
an IO_APIC in the motherboard chipset, normal timer interrupt, actually
if you configure with CONFIG_X86_IO_APIC and no io_apic is avalaible
we fail silently.