From: <al...@fc...> - 2004-02-03 01:28:09
|
Hello: I've been trying out the 2.6 interface of oprofile and am having some trouble. On my laptop, I get no samples at all, i.e. no sample files are created under current. I'm using oprofile 0.7.1 and the 2.6.1 kernel. This setup works fine on the i386 server machine. Oprofile says it's using the timer interrupt (is there a way on 2.6 to use rtc instead on a machine with a disabled apic?) and the daemonrc is: NR_CHOSEN=0 SEPARATE_LIB=1 SEPARATE_KERNEL=1 SEPARATE_THREAD=1 SEPARATE_CPU=1 VMLINUX=/usr/src/linux-2.6.1/vmlinux IMAGE_FILTER= The module is loaded: Module Size Used by oprofile 28768 1 And dmesg says: oprofile: using NMI timer interrupt. Profiling is enabled in the kernel: # # Profiling support # CONFIG_PROFILING=y CONFIG_OPROFILE=m A verbose log of the daemon shows: oprofiled started Mon Feb 2 18:13:57 2004 kernel pointer size: 4 Read buffer of 747 entries. CPU_SWITCH to 0 ... [repeats 246 times] ... CPU_SWITCH to 0 Read buffer of 516 entries. CPU_SWITCH to 0 ... [repeats 169 times] ... CPU_SWITCH to 0 Read buffer of 30 entries. CPU_SWITCH to 0 ... [repeats 8 times] ... CPU_SWITCH to 0 Mon Feb 2 18:14:24 2004 Nr. sample dumps: 3 Nr. samples total: 0 Nr. kernel samples: 0 Nr. lost samples (no kernel/user): 0 Nr. lost kernel samples: 0 Nr. incomplete code structs: 0 oprofiled stopped Mon Feb 2 18:14:24 2004 Any hints? Thanks, Alex Tsariounov |
From: William C. <wc...@nc...> - 2004-02-03 02:51:52
|
What kind of processor is in the laptop? Is this a laptop with blacklisted APIC hardware? Could you send the /proc/cpuinfo? Is there any information about the APIC in /var/log/dmesg or /var/log/messages? Does the watchdog timer work on the machine? Append "nmi_watchdog=2" to the kernel startup parameters. This uses the same hardware set up as OProfile. If this works, the problem is specific to the OProfile code. Any messages from /var/log/messages about the "NMI watchdog" in /var/log/dmesg? Maybe OProfile is getting it wrong about the APIC hardware. If the APIC wasn't available, OProfile should fall back to the timer_int mechanism. Every jiffy a sample is taken. It isn't as flexible as the RTC mechanism in the 2.4 driver; you cannot set the sample rate. -Will Alex Tsariounov wrote: > Hello: > > I've been trying out the 2.6 interface of oprofile and am > having some trouble. On my laptop, I get no samples at all, > i.e. no sample files are created under current. I'm using > oprofile 0.7.1 and the 2.6.1 kernel. > > This setup works fine on the i386 server machine. > > Oprofile says it's using the timer interrupt (is there a way > on 2.6 to use rtc instead on a machine with a disabled > apic?) and the daemonrc is: > > NR_CHOSEN=0 > SEPARATE_LIB=1 > SEPARATE_KERNEL=1 > SEPARATE_THREAD=1 > SEPARATE_CPU=1 > VMLINUX=/usr/src/linux-2.6.1/vmlinux > IMAGE_FILTER= > > The module is loaded: > > Module Size Used by > oprofile 28768 1 > > And dmesg says: > > oprofile: using NMI timer interrupt. > > Profiling is enabled in the kernel: > > # > # Profiling support > # > CONFIG_PROFILING=y > CONFIG_OPROFILE=m > > A verbose log of the daemon shows: > > oprofiled started Mon Feb 2 18:13:57 2004 > kernel pointer size: 4 > Read buffer of 747 entries. > CPU_SWITCH to 0 > ... [repeats 246 times] ... > CPU_SWITCH to 0 > Read buffer of 516 entries. > CPU_SWITCH to 0 > ... [repeats 169 times] ... > CPU_SWITCH to 0 > Read buffer of 30 entries. > CPU_SWITCH to 0 > ... [repeats 8 times] ... > CPU_SWITCH to 0 > > Mon Feb 2 18:14:24 2004 > > Nr. sample dumps: 3 > Nr. samples total: 0 > Nr. kernel samples: 0 > Nr. lost samples (no kernel/user): 0 > Nr. lost kernel samples: 0 > Nr. incomplete code structs: 0 > oprofiled stopped Mon Feb 2 18:14:24 2004 > > Any hints? > > Thanks, > Alex Tsariounov > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list > |
From: Alex T. <al...@fc...> - 2004-02-03 19:52:16
|
On Mon, Feb 02, 2004 at 09:50:07PM -0500, William Cohen wrote: > What kind of processor is in the laptop? Is this a laptop with > blacklisted APIC hardware? Could you send the /proc/cpuinfo? It's a p3: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 6 cpu MHz : 846.607 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1675.26 > Is there any information about the APIC in /var/log/dmesg or > /var/log/messages? 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 > Does the watchdog timer work on the machine? Append "nmi_watchdog=2" to > the kernel startup parameters. This uses the same hardware set up as > OProfile. If this works, the problem is specific to the OProfile code. > Any messages from /var/log/messages about the "NMI watchdog" in > /var/log/dmesg? I'll try that, but I've never been able to use the APIC->NMI method with this laptop on 2.4 kernels, I've always had to use the RTC. The questions is why no samples are getting out however. There are buffers being read, the kernel is sampling presumably, and the daemon is reading buffers, however, there seem to be no samples in there. Is there a way to get the raw buffers out somehow, translated into ascii preferably? > Maybe OProfile is getting it wrong about the APIC hardware. If the APIC > wasn't available, OProfile should fall back to the timer_int mechanism. > Every jiffy a sample is taken. It isn't as flexible as the RTC mechanism > in the 2.4 driver; you cannot set the sample rate. 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? Thanks a bunch, Alex |
From: Alex T. <al...@fc...> - 2004-02-03 19:11:12
|
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. > >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. > >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? Thanks, Alex |
From: Philippe E. <ph...@wa...> - 2004-02-04 00:49:25
|
On Tue, 03 Feb 2004 at 11:05 +0000, Alex Tsariounov wrote: > 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 anwser in the other thread, it's a bug in 2.6 doprofile > > > >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. > > > >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? > > Thanks, > Alex > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: Alex T. <al...@fc...> - 2004-02-03 20:13:41
|
On Tue, Feb 03, 2004 at 09:01:42PM +0000, Philippe Elie wrote: > > 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 anwser in the other thread, it's a bug in 2.6 doprofile Ah, ok, that clarifies it. :) But your earlier reply said that IO_APIC was not set/or disabled, and it is set, just not functional on this laptop. Oh, I see, you're saying that although oprofile does say it is using the timer_int, it is not doing that correctly because it thinks that an IO_APIC is available but it's not. So the cure then is to disable the IO_APIC in the kernel config file? I'll try that. Thanks, Alex |
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 |
From: Alex T. <al...@fc...> - 2004-02-03 22:12:05
|
On Tue, Feb 03, 2004 at 09:14:33PM +0000, Philippe Elie wrote: > On Tue, 03 Feb 2004 at 11:05 +0000, Alex Tsariounov wrote: > > Sorry mail accidentally send ... ignore my last mail Ah, yes, that explains all. Thank you. Alex |
From: Alex T. <al...@fc...> - 2004-02-04 18:32:01
|
On Tue, Feb 03, 2004 at 09:14:33PM +0000, Philippe Elie wrote: > 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; > } So, considering that you can't enable the IO_APIC without first enabling the LOCAL_APIC anyway, at least if you use menuconfig, could we change the above code in init.c to: int __init oprofile_arch_init(struct oprofile_operations ** ops) { int ret = -ENODEV; #ifdef CONFIG_X86_LOCAL_APIC ret = nmi_init(ops); #ifdef CONFIG_X86_IO_APIC if (ret < 0) ret = nmi_timer_init(ops); #endif #endif return ret; } to match the configure options and thus avoid the problem I'm seeing? Alex Tsariounov |
From: Alex T. <al...@fc...> - 2004-02-04 18:39:28
|
On Wed, Feb 04, 2004 at 11:28:13AM -0700, Alex Tsariounov wrote: > So, considering that you can't enable the IO_APIC without > first enabling the LOCAL_APIC anyway, at least if you use > menuconfig, could we change the above code in init.c to: Arrgh, never mind, that change won't make a difference. Don't know what I was thinking. Alex Tsasriounov |
From: Alex T. <al...@fc...> - 2004-02-05 02:28:33
|
On Tue, Feb 03, 2004 at 09:14:33PM +0000, Philippe Elie wrote: > 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. That solved the problem for me: disabling the APIC/IO_APIC config. Too bad that the driver can't figure that out so that, as you said, we could use the same config for smp/nonsmp systems. Oh, and some distros will build UP with APIC/IO_APIC enabled by default. Debian for example does this for the 2.4 series kernels and probably will for 2.6 as well - as they should since if a good APIC is there oprofile can use the PMCs. Thanks for the help, Alex |
From: Zwane M. <zw...@ar...> - 2004-02-05 19:08:27
|
On Tue, 3 Feb 2004, Philippe Elie wrote: > 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. Hopefully this takes care of that, it's been tested here and does the right thing on both my UP and SMP box (uses NMI timer int). Index: linux-2.6.2/arch/i386/kernel/nmi.c =================================================================== RCS file: /home/cvsroot/linux-2.6.2/arch/i386/kernel/nmi.c,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 nmi.c --- linux-2.6.2/arch/i386/kernel/nmi.c 4 Feb 2004 07:43:40 -0000 1.1.1.1 +++ linux-2.6.2/arch/i386/kernel/nmi.c 5 Feb 2004 18:11:36 -0000 @@ -42,7 +42,7 @@ extern void show_registers(struct pt_reg * be enabled * -1: the lapic NMI watchdog is disabled, but can be enabled */ -static int nmi_active; +int nmi_active; #define K7_EVNTSEL_ENABLE (1 << 22) #define K7_EVNTSEL_INT (1 << 20) Index: linux-2.6.2/arch/i386/oprofile/nmi_timer_int.c =================================================================== RCS file: /home/cvsroot/linux-2.6.2/arch/i386/oprofile/nmi_timer_int.c,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 nmi_timer_int.c --- linux-2.6.2/arch/i386/oprofile/nmi_timer_int.c 4 Feb 2004 07:43:41 -0000 1.1.1.1 +++ linux-2.6.2/arch/i386/oprofile/nmi_timer_int.c 5 Feb 2004 18:45:04 -0000 @@ -48,9 +48,13 @@ static struct oprofile_operations nmi_ti .cpu_type = "timer" }; - int __init nmi_timer_init(struct oprofile_operations ** ops) { + extern int nmi_active; + + if (nmi_active <= 0) + return -ENODEV; + *ops = &nmi_timer_ops; printk(KERN_INFO "oprofile: using NMI timer interrupt.\n"); return 0; |
From: Philippe E. <ph...@wa...> - 2004-02-05 19:39:02
|
On Thu, 05 Feb 2004 at 14:07 +0000, Zwane Mwaikambo wrote: > On Tue, 3 Feb 2004, Philippe Elie wrote: > > > 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. > > Hopefully this takes care of that, it's been tested here and does the > right thing on both my UP and SMP box (uses NMI timer int). > > Index: linux-2.6.2/arch/i386/kernel/nmi.c > =================================================================== > RCS file: /home/cvsroot/linux-2.6.2/arch/i386/kernel/nmi.c,v > retrieving revision 1.1.1.1 > diff -u -p -B -r1.1.1.1 nmi.c > --- linux-2.6.2/arch/i386/kernel/nmi.c 4 Feb 2004 07:43:40 -0000 1.1.1.1 > +++ linux-2.6.2/arch/i386/kernel/nmi.c 5 Feb 2004 18:11:36 -0000 > @@ -42,7 +42,7 @@ extern void show_registers(struct pt_reg > * be enabled > * -1: the lapic NMI watchdog is disabled, but can be enabled > */ > -static int nmi_active; > +int nmi_active; don't we need to export nmi_active ? There is also a corner case, if CONFIG_WATCHDOG=n we always fallback to timer_int not to timer_nmi_int() but I don't take care about that. If you fix the export problem send it to akpm and lkml please, I pre-approve this fix. regards, Phil |
From: Zwane M. <zw...@ar...> - 2004-02-05 22:06:07
|
On Thu, 5 Feb 2004, Philippe Elie wrote: > don't we need to export nmi_active ? There is also a corner case, Ok forgot that bit, updated locally. > if CONFIG_WATCHDOG=n we always fallback to timer_int not to > timer_nmi_int() but I don't take care about that. Well the NMI watchdog is always enabled when you configure the APICs so this should envelope that. > If you fix the export problem send it to akpm and lkml please, I > pre-approve > this fix. Thanks, i'll send it off shortly. Zwane |
From: Philippe E. <ph...@wa...> - 2004-02-03 04:00:20
|
On Mon, 02 Feb 2004 at 18:24 +0000, Alex Tsariounov wrote: > Hello: > > I've been trying out the 2.6 interface of oprofile and am > having some trouble. On my laptop, I get no samples at all, > i.e. no sample files are created under current. I'm using > oprofile 0.7.1 and the 2.6.1 kernel. > > This setup works fine on the i386 server machine. > > Oprofile says it's using the timer interrupt (is there a way > on 2.6 to use rtc instead on a machine with a disabled > apic?) and the daemonrc is: No, the 2.6 driver should recover but ... > The module is loaded: > > Module Size Used by > oprofile 28768 1 > > And dmesg says: > > oprofile: using NMI timer interrupt. You configured your kernel with CONFIG_X86_IO_APIC but w/o an IO_APIC or a disabled IO_APIC, the driver doesn't fallback correctly to "normal" timer_int (non nmi variant) I don't see how to fix it easily, there is apparently no exported variable from the kernel to check if the io apic is up. Zwane is it correct ? > Read buffer of 30 entries. > CPU_SWITCH to 0 > ... [repeats 8 times] ... > CPU_SWITCH to 0 > > Mon Feb 2 18:14:24 2004 > > Nr. sample dumps: 3 > Nr. samples total: 0 > Nr. kernel samples: 0 > Nr. lost samples (no kernel/user): 0 > Nr. lost kernel samples: 0 > Nr. incomplete code structs: 0 > oprofiled stopped Mon Feb 2 18:14:24 2004 > > Any hints? regards, Phil |
From: Alex T. <al...@fc...> - 2004-02-03 18:17:01
|
On Tue, Feb 03, 2004 at 05:17:20AM +0000, Philippe Elie wrote: > > And dmesg says: > > > > oprofile: using NMI timer interrupt. > > You configured your kernel with CONFIG_X86_IO_APIC but w/o an IO_APIC > or a disabled IO_APIC, the driver doesn't fallback correctly to "normal" > timer_int (non nmi variant) I don't see how to fix it easily, there > is apparently no exported variable from the kernel to check if the io > apic is up. No, the APIC configs are and the IOAPIC is on: CONFIG_PREEMPT=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_TSC=y CONFIG_X86_MCE=y But see my reply to Will's questions since the APIC->NMI never worked on this laptop - I've always had to use RTC for 2.4 kernels. Thanks, Alex |