The original message was received at Mon, 11 Mar 2019 11:44:43 +0800
from lists.01.org [32.243.43.235]
- The following addresses had permanent fatal errors -
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Sebastian Andrzej Siewior
> Sent: Friday, March 8, 2019 17:42
> To: Liu, Yongxin
> Cc: linux-ker...@vger.kernel.org; linux-rt-us...@vger.kernel.org;
>
On Sun, Mar 10, 2019 at 4:54 PM Dan Williams wrote:
>
> Unfortunately this particular b0rkage is not constrained to nvmem.
> I.e. there's nothing specific about nvmem requiring mc-safe memory
> copy, it's a cpu problem consuming any poison regardless of
> source-media-type with "rep; movs".
So
[ add Tony, who has wrestled with how to detect rep; movs recover-ability ]
On Sun, Mar 10, 2019 at 1:02 PM Linus Torvalds
wrote:
>
> On Sun, Mar 10, 2019 at 12:54 PM Dan Williams
> wrote:
> >
> > Hi Linus, please pull from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
On Sun, Mar 10, 2019 at 12:54 PM Dan Williams wrote:
>
> Hi Linus, please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
> tags/devdax-for-5.1
>
> ...to receive new device-dax infrastructure to allow persistent memory
> and other "reserved" / performance
Hi Linus, please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
tags/devdax-for-5.1
...to receive new device-dax infrastructure to allow persistent memory
and other "reserved" / performance differentiated memories, to be
assigned to the core-mm as "System RAM".
While
