![]() | |||||||||||||
Messages in this thread |
On 11/22/06, Andrew Morton <akpm@osdl.org> wrote: > On Wed, 22 Nov 2006 11:36:14 +0100 > Andi Kleen <ak@suse.de> wrote: > > > On Wednesday 22 November 2006 11:28, Eric Dumazet wrote: > > > On Wednesday 15 November 2006 11:35, Eric Dumazet wrote: > > > > On Wednesday 15 November 2006 11:21, Adrian Bunk wrote: > > > > > Subject : x86_64: oprofile doesn't work > > > > > References : http://lkml.org/lkml/2006/10/27/3 > > > > > Submitter : Prakash Punnoor <prakash@punnoor.de> > > > > > Status : unknown > > > > > > > > > > I hit the same problem on i386 architecture too, if CONFIG_ACPI is not set. > > > > oprofile is still broken because it cannot deal with the lack of perfctr 0. > > The kernel is still broken because we changed the interface. I just got bit by this on 2.6.20-latest (well, of two days ago anyway) while trying to debug another transient 'kacpid sucks all available cpu time'. But that's okay, I'm sure it will happen again in a week or two. In the meantime, who won this pis^H^H^H discussion? Mikael Pettersson wrote: > Andrew Morton writes: > > Surely the appropriate behaviour is to allow oprofile to steal the NMI and > > to then put the NMI back to doing the watchdog thing after oprofile has > > finished with it. > > Which is _exactly_ what pre-2.6.19-rc1 kernels did. I implemented > the in-kernel API allowing real performance counter drivers like > oprofile (and perfctr) to claim the HW from the NMI watchdog, > do their work, and then release it which resumed the watchdog. > > Note that oprofile (and perfctr) didn't do anything behind the > NMI watchdog's back. They went via the API. Nothing dodgy going on. Well, that seems clear. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-12-16 12:23 [from the cache] ©2003-2008 | |||||||||||||