From: Philippe E. <ph...@wa...> - 2004-02-05 11:11:50
|
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; #ifdef CONFIG_X86_LOCAL_APIC ret = nmi_init(ops); #endif #ifdef CONFIG_X86_IO_APIC if (ret < 0) ret = nmi_timer_init(ops); #endif return ret; } 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 > option. 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. regards, Phil |