On Sun, 13 May 2007 16:38:16 -0400 Benjamin LaHaise <[EMAIL PROTECTED]> wrote:
> On Sat, May 05, 2007 at 11:31:20AM +0200, Andi Kleen wrote: > > Hmm, after a opcontrol --reset i see the same issue now. Don't know what's > > wrong, but it must be something different from the .20 perfctr allocation > > problem. > > > > It looks like the daemon doesn't get any data from the kernel > > I finally had time to track this down. The breakage is caused by "[PATCH] > x86-64: Let oprofile reserve MSR on all CPUs". Oprofile is already calling > the reserve functions on each CPU in the system when it sets up the MSRs. > This results in oprofile getting a reservation failure on CPUs above 0. The > following makes oprofile adapt to the API change for now -- oprofile > still needs to be modified to perform the reservations earlier during its > initialization, but that's a little bit more involved than the immediate > bug fix. This only affects systems with more than 1 CPU. This patch has > been through limited testing (Athlon 64 X2 and Core 2, but not on the P4) on > x86 and x86-64 (Core 2 only). Unfortunately we've left this a bit too late - your patch is patching code which isn't there any more in mainline and we also need a 2.6.21.x fix. So perhaps we could merge your "immediate bugfix" into -stable and implement the "more involved" fix for 2.6.22. Andi, any preferences? - 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/