Re: [discuss] Re: 2.6.19-rc5: known regressions (v3)

[Andrew Morton <akpm@osdl.org>]

On Wed, 15 Nov 2006 14:18:24 -0700
ebiederm@xmission.com (Eric W. Biederman) wrote:

> Andrew Morton <akpm@osdl.org> writes:
> 
> > Is it correct to say that oprofile-on-2.6.18 works, and that
> > oprofile-on-2.6.19-rc5 does not?
> >
> > Or is there some sort of workaround for this, or does 2.6.19-rc5 only fail
> > in some particular scenarios?
> >
> > If it's really true that oprofile is simply busted then that's a serious
> > problem and we should find some way of unbusting it.  If that means just
> > adding a dummy "0" entry which always returns zero or something like that,
> > then fine.
> >
> > But we can't just go and bust it.
> 
> The simple question.  If we turn off the NMI watchdog on 2.6.19-rc5 
> does oprofile work?  I believe that is what Andi said.
> 
> The description I read was a resource conflict. The resources oprofile
> just expects it can used are already in use so we tell it no and
> the user space oprofile doesn't cope.

That would have been a bug in earlier kernels.

> Now I don't know the interface allows us to rename the interfaces
> from 1 2 3 to 0 1 2.  If we can then that looks like something we can
> fix.  Otherwise from the description I tend to agree with Andi.
> 
> The user space application assumed it own hardware that it did not.
> 
> Hmm.  I bet if nothing else we could move the NMI watchdog from 0 to 3
> and make things work that way...

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.

If that's not a feasible thing to do for 2.6.19 then some short-term
hack which makes oprofile work again is needed.