On Fri, Jun 15, 2018 at 09:34:06AM -0700, Luck, Tony wrote:
> I was just worried that Thomas is holding off asking Linus to pull
> because he's waiting for part 2/3, while you might be planning to
> hold onto part 2/3 for the next merge (and add the other cleanups
> you RFC'd).
>
> I'm OK either
On Fri, Jun 15, 2018 at 09:34:06AM -0700, Luck, Tony wrote:
> I was just worried that Thomas is holding off asking Linus to pull
> because he's waiting for part 2/3, while you might be planning to
> hold onto part 2/3 for the next merge (and add the other cleanups
> you RFC'd).
>
> I'm OK either
On Fri, Jun 15, 2018 at 01:45:18PM +0200, Borislav Petkov wrote:
> On Thu, Jun 14, 2018 at 02:57:54PM -0700, Luck, Tony wrote:
> > On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote:
> > > tglx just took 1 and 3, 2/3 had a minor issue but the merge window
> > > happened so I'll send
On Fri, Jun 15, 2018 at 01:45:18PM +0200, Borislav Petkov wrote:
> On Thu, Jun 14, 2018 at 02:57:54PM -0700, Luck, Tony wrote:
> > On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote:
> > > tglx just took 1 and 3, 2/3 had a minor issue but the merge window
> > > happened so I'll send
On Thu, Jun 14, 2018 at 02:57:54PM -0700, Luck, Tony wrote:
> On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote:
> > tglx just took 1 and 3, 2/3 had a minor issue but the merge window
> > happened so I'll send it later. It is nice to have anyway.
>
> Did you fix up part 2/3?
You
On Thu, Jun 14, 2018 at 02:57:54PM -0700, Luck, Tony wrote:
> On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote:
> > tglx just took 1 and 3, 2/3 had a minor issue but the merge window
> > happened so I'll send it later. It is nice to have anyway.
>
> Did you fix up part 2/3?
You
On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote:
> tglx just took 1 and 3, 2/3 had a minor issue but the merge window
> happened so I'll send it later. It is nice to have anyway.
Did you fix up part 2/3? I see 1 & 3 were staged by Thomas in
TIP ras/urgent and ras-urgent-for-linus
On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote:
> tglx just took 1 and 3, 2/3 had a minor issue but the merge window
> happened so I'll send it later. It is nice to have anyway.
Did you fix up part 2/3? I see 1 & 3 were staged by Thomas in
TIP ras/urgent and ras-urgent-for-linus
On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote:
> On Thu, Jun 07, 2018 at 01:18:31PM -0700, Dan Williams wrote:
> > I'm making an effort to get all persistent memory error handling holes
> > covered this cycle, so I think it makes sense for this to go through
> > the nvdimm tree.
On Thu, Jun 07, 2018 at 10:24:46PM +0200, Borislav Petkov wrote:
> On Thu, Jun 07, 2018 at 01:18:31PM -0700, Dan Williams wrote:
> > I'm making an effort to get all persistent memory error handling holes
> > covered this cycle, so I think it makes sense for this to go through
> > the nvdimm tree.
On Thu, 7 Jun 2018, Dan Williams wrote:
> On Thu, Jun 7, 2018 at 10:43 AM, Luck, Tony wrote:
> > On Fri, May 25, 2018 at 02:42:09PM -0700, Tony Luck wrote:
> >> Currently we just check the "CAPID0" register to see whether the CPU
> >> can recover from machine checks.
> >>
> >> But there are
On Thu, 7 Jun 2018, Dan Williams wrote:
> On Thu, Jun 7, 2018 at 10:43 AM, Luck, Tony wrote:
> > On Fri, May 25, 2018 at 02:42:09PM -0700, Tony Luck wrote:
> >> Currently we just check the "CAPID0" register to see whether the CPU
> >> can recover from machine checks.
> >>
> >> But there are
On Thu, Jun 07, 2018 at 01:18:31PM -0700, Dan Williams wrote:
> I'm making an effort to get all persistent memory error handling holes
> covered this cycle, so I think it makes sense for this to go through
> the nvdimm tree. This looks sufficiently non-controversial that I
> could justify sending
On Thu, Jun 07, 2018 at 01:18:31PM -0700, Dan Williams wrote:
> I'm making an effort to get all persistent memory error handling holes
> covered this cycle, so I think it makes sense for this to go through
> the nvdimm tree. This looks sufficiently non-controversial that I
> could justify sending
On Thu, Jun 7, 2018 at 10:43 AM, Luck, Tony wrote:
> On Fri, May 25, 2018 at 02:42:09PM -0700, Tony Luck wrote:
>> Currently we just check the "CAPID0" register to see whether the CPU
>> can recover from machine checks.
>>
>> But there are also some special SKUs which do not have all advanced
>>
On Thu, Jun 7, 2018 at 10:43 AM, Luck, Tony wrote:
> On Fri, May 25, 2018 at 02:42:09PM -0700, Tony Luck wrote:
>> Currently we just check the "CAPID0" register to see whether the CPU
>> can recover from machine checks.
>>
>> But there are also some special SKUs which do not have all advanced
>>
On Fri, May 25, 2018 at 02:42:09PM -0700, Tony Luck wrote:
> Currently we just check the "CAPID0" register to see whether the CPU
> can recover from machine checks.
>
> But there are also some special SKUs which do not have all advanced
> RAS features, but do enable machine check recovery for use
On Fri, May 25, 2018 at 02:42:09PM -0700, Tony Luck wrote:
> Currently we just check the "CAPID0" register to see whether the CPU
> can recover from machine checks.
>
> But there are also some special SKUs which do not have all advanced
> RAS features, but do enable machine check recovery for use
Currently we just check the "CAPID0" register to see whether the CPU
can recover from machine checks.
But there are also some special SKUs which do not have all advanced
RAS features, but do enable machine check recovery for use with NVDIMMs.
Add a check for any of bits {8:5} in the "CAPID5"
Currently we just check the "CAPID0" register to see whether the CPU
can recover from machine checks.
But there are also some special SKUs which do not have all advanced
RAS features, but do enable machine check recovery for use with NVDIMMs.
Add a check for any of bits {8:5} in the "CAPID5"
20 matches
Mail list logo
