On Wed, Oct 17, 2018 at 7:41 AM Razvan Cojocaru
wrote:
>
> On 10/5/18 2:00 PM, Razvan Cojocaru wrote:
> > On 9/27/18 2:25 PM, George Dunlap wrote:
> >> The name of the "with_gla" flag is confusing; it has nothing to do
> >> with the existence or lack thereof of a faulting GLA, but rather where
> >
On 10/5/18 2:00 PM, Razvan Cojocaru wrote:
> On 9/27/18 2:25 PM, George Dunlap wrote:
>> The name of the "with_gla" flag is confusing; it has nothing to do
>> with the existence or lack thereof of a faulting GLA, but rather where
>> the fault originated. The npfec.kind value is always valid, and
>
On 9/27/18 2:25 PM, George Dunlap wrote:
> The name of the "with_gla" flag is confusing; it has nothing to do
> with the existence or lack thereof of a faulting GLA, but rather where
> the fault originated. The npfec.kind value is always valid, and
> should thus be propagated, regardless of whethe
On Thu, 2018-09-27 at 12:25 +0100, George Dunlap wrote:
> The name of the "with_gla" flag is confusing; it has nothing to do
> with the existence or lack thereof of a faulting GLA, but rather
> where
> the fault originated. The npfec.kind value is always valid, and
> should thus be propagated, reg
On 27/09/18 12:25, George Dunlap wrote:
> The name of the "with_gla" flag is confusing; it has nothing to do
> with the existence or lack thereof of a faulting GLA, but rather where
> the fault originated. The npfec.kind value is always valid, and
> should thus be propagated, regardless of whether
