On Mon, 2014-09-15 at 16:54 -0700, Nishanth Aravamudan wrote:
> On 15.09.2014 [15:05:36 +1000], Michael Ellerman wrote:
> > On Tue, 2014-09-09 at 13:09 -0700, Nishanth Aravamudan wrote:
>
> > Does it really need to be a boot param, or could it be a debugfs or
> > sysctl flag? ie. do we need to dis
On 16.09.2014 [14:42:20 -0500], Nathan Fontenot wrote:
>
>
> On 09/09/2014 03:09 PM, Nishanth Aravamudan wrote:
> > We have hit a few customer issues with the topology update code (VPHN
> > and PRRN). It would be nice to be able to debug the notifications coming
> > from the hypervisor in both ca
On 09/09/2014 03:09 PM, Nishanth Aravamudan wrote:
> We have hit a few customer issues with the topology update code (VPHN
> and PRRN). It would be nice to be able to debug the notifications coming
> from the hypervisor in both cases to the LPAR, as well as to disable
> reacting to the notificati
Hi Michael,
On 15.09.2014 [15:05:36 +1000], Michael Ellerman wrote:
> On Tue, 2014-09-09 at 13:09 -0700, Nishanth Aravamudan wrote:
> > We have hit a few customer issues with the topology update code (VPHN
> > and PRRN). It would be nice to be able to debug the notifications coming
> > from the hy
On Tue, 2014-09-09 at 13:09 -0700, Nishanth Aravamudan wrote:
> We have hit a few customer issues with the topology update code (VPHN
> and PRRN). It would be nice to be able to debug the notifications coming
> from the hypervisor in both cases to the LPAR, as well as to disable
> reacting to the n
We have hit a few customer issues with the topology update code (VPHN
and PRRN). It would be nice to be able to debug the notifications coming
from the hypervisor in both cases to the LPAR, as well as to disable
reacting to the notifications, to narrow down the source of the
problems. Add a basic l
