Re: perf hw in kexeced kernel broken in tip

[Vivek Goyal <vgoyal@redhat.com>]

On Wed, Dec 08, 2010 at 03:20:05PM +0100, Peter Zijlstra wrote:
> On Wed, 2010-12-08 at 09:01 -0500, Don Zickus wrote:
> > On Wed, Dec 08, 2010 at 12:30:20AM +0100, Peter Zijlstra wrote:
> > > On Thu, 2010-12-02 at 11:15 -0500, Don Zickus wrote:
> > > 
> > > > Vivek suggested to me this morning that I should just blantantly disable the
> > > > perf counter during init when running my test. 
> > > 
> > > Nah, we should actively scan for that during the bring-up and kill
> > > hw-perf when we find an enable bit set, some BIOSes actively use the
> > > PMU, this is something that should be discouraged.
> > 
> > Ok, the reboot notifier addresses the kexec problem but doesn't fix it
> > though (I have to test to confirm that, comments below).  
> 
> 
> > The bios check
> > should catch those situations (ironically I stumbled upon a machine with
> > this problem, so I will test your patch with it, though it only uses perf
> > counter 0). 
> 
> Right, they usually only steal one or two counters, but the fact that
> they're using them at all is insane and should be punished.
> 
> >  The kdump problem will still exist, not sure if we care and
> > perhaps we should document in the changelog that we know kdump is still
> > broken (unless we do care).
> 
> You mean even if we cure the kexec reboot notifier patch thing kdump is
> still borken?
> 

Yes. reboot notifier notifications are not sent in kdump path. In this
path we know kernel has crashed and we just try to do bare minimal things
to boot into second kernel. If some hardware is left in inconsistent
state we try to recover from that situation by resetting the device
when second kernel is booting.

Either driver itself can detect that device is in inconsistent state and
reset it otherwise we also pass a command line parameter "reset_devices" to
second kernel to explicitly tell kernel that devices might be in bad state,
reset these during initialization. If we want to use these perf counters in
kdump kernel, we shall have to do something similar.

Thanks
Vivek