diff for duplicates of <20190510154904.GA31649@lst.de> diff --git a/a/1.txt b/N1/1.txt index bb1b675..e8ebff3 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,10 +1,10 @@ -On Fri, May 10, 2019@11:18:52PM +0800, Kai Heng Feng wrote: +On Fri, May 10, 2019 at 11:18:52PM +0800, Kai Heng Feng wrote: > > I'm afraid the requirement is still not clear to me. AFAIK, all our > > barriers routines ensure data is visible either between CPUs, or between > > CPU and devices. The CPU never accesses HMB memory, so there must be some > > other reasoning if this barrier is a real requirement for this device. > -> Sure, I?ll ask vendor what that MemRd is for. +> Sure, I’ll ask vendor what that MemRd is for. I'd like to understand this bug, but this thread leaves me a little confused. So we have a NVMe driver with HMB. diff --git a/a/content_digest b/N1/content_digest index eba1c7a..4909a18 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -8,18 +8,32 @@ "ref\0BC5EB1D0-8718-48B3-ACAB-F7E5571D821D@canonical.com\0" "ref\020190510140209.GG9675@localhost.localdomain\0" "ref\0D2D197AF-0072-42AC-A844-8D6BC9677949@canonical.com\0" - "From\0hch@lst.de (hch@lst.de)\0" - "Subject\0[PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle\0" + "From\0hch@lst.de <hch@lst.de>\0" + "Subject\0Re: [PATCH] nvme-pci: Use non-operational power state instead of D3 on Suspend-to-Idle\0" "Date\0Fri, 10 May 2019 17:49:04 +0200\0" + "To\0Kai Heng Feng <kai.heng.feng@canonical.com>\0" + "Cc\0Keith Busch <kbusch@kernel.org>" + Mario.Limonciello@dell.com <Mario.Limonciello@dell.com> + hch@lst.de <hch@lst.de> + axboe@fb.com <axboe@fb.com> + sagi@grimberg.me <sagi@grimberg.me> + rafael@kernel.org <rafael@kernel.org> + linux-pm@vger.kernel.org <linux-pm@vger.kernel.org> + Wysocki + Rafael J <rafael.j.wysocki@intel.com> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + linux-nvme@lists.infradead.org <linux-nvme@lists.infradead.org> + Busch + " Keith <keith.busch@intel.com>\0" "\00:1\0" "b\0" - "On Fri, May 10, 2019@11:18:52PM +0800, Kai Heng Feng wrote:\n" + "On Fri, May 10, 2019 at 11:18:52PM +0800, Kai Heng Feng wrote:\n" "> > I'm afraid the requirement is still not clear to me. AFAIK, all our\n" "> > barriers routines ensure data is visible either between CPUs, or between\n" "> > CPU and devices. The CPU never accesses HMB memory, so there must be some\n" "> > other reasoning if this barrier is a real requirement for this device.\n" "> \n" - "> Sure, I?ll ask vendor what that MemRd is for.\n" + "> Sure, I\342\200\231ll ask vendor what that MemRd is for.\n" "\n" "I'd like to understand this bug, but this thread leaves me a little\n" "confused. So we have a NVMe driver with HMB.\n" @@ -39,4 +53,4 @@ "pm methods? We'll then need to disable the HMB, which might suck\n" in terms of latency. -9b3cca12a1105d17f527ad588d08985b3fc4590fb7680ba03f5cf7449fcde7a4 +ed4d7e4c47d46aecf1ee188f00c37dce3e5a3b5fc77f07d96cf9359a4b95665d
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.