On Tue, Mar 20, 2007 at 08:36:27AM -0800, Andrew Morton wrote: > > caller is avail_to_resrv_perfctr_nmi_bit+0x2b/0x43 > > [<c0105256>] show_trace_log_lvl+0x1a/0x2f > > [<c010597b>] show_trace+0x12/0x14 > > [<c0105a3d>] dump_stack+0x16/0x18 > > [<c0213313>] debug_smp_processor_id+0xb3/0xc8 > > [<c0116a26>] avail_to_resrv_perfctr_nmi_bit+0x2b/0x43 > > [<fdc819b9>] nmi_create_files+0x2a/0x10e [oprofile] > > [<fdc80f52>] oprofile_create_files+0xe6/0xec [oprofile] > > [<fdc81157>] oprofilefs_fill_super+0x78/0x7e [oprofile] > > [<c0182d2e>] get_sb_single+0x59/0x9f > > [<fdc8108f>] oprofilefs_get_sb+0x1c/0x1e [oprofile] > > [<c0182792>] vfs_kern_mount+0x81/0xf1 > > [<c0182852>] do_kern_mount+0x38/0xde > > [<c0196671>] do_mount+0x605/0x693 > > [<c019677f>] sys_mount+0x80/0xb5 > > [<c0104270>] syscall_call+0x7/0xb > > ======================= > > Odd. It looks like oprofile has been doing this for some time. Andi, > there are a few changes in the NMI area - can you think of one whihc would > have triggered this?
Looks like it was always broken. avail_to_resrv_perfctr_nmi_bit() must always do all this for all possible CPUs, not just the current one. I can cook up a patch. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
