diff for duplicates of <1493019397.3171.118.camel@oracle.com> diff --git a/a/1.txt b/N1/1.txt index f3baee4..8c7eb62 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,12 +1,12 @@ -On Mon, 2017-04-17 at 08:31 +1000, Benjamin Herrenschmidt wrote: -> On Sun, 2017-04-16 at 10:34 -0600, Logan Gunthorpe wrote: -> > +On Mon, 2017-04-17@08:31 +1000, Benjamin Herrenschmidt wrote: +> On Sun, 2017-04-16@10:34 -0600, Logan Gunthorpe wrote: +> >? > > On 16/04/17 09:53 AM, Dan Williams wrote: > > > ZONE_DEVICE allows you to redirect via get_dev_pagemap() to retrieve > > > context about the physical address in question. I'm thinking you can > > > hang bus address translation data off of that structure. This seems > > > vaguely similar to what HMM is doing. -> > +> >? > > Thanks! I didn't realize you had the infrastructure to look up a device > > from a pfn/page. That would really come in handy for us. > @@ -28,18 +28,18 @@ On Mon, 2017-04-17 at 08:31 +1000, Benjamin Herrenschmidt wrote: > "dma_ops override" backend. We can have generic code to handle the case > where devices reside on the same domain, which can deal with switch > configuration etc... we will need to have iommu specific code to handle -> the case going through the fabric. +> the case going through the fabric.? > > Virtualization is a separate can of worms due to how qemu completely > fakes the MMIO space, we can look into that later. My first reflex when reading this thread was to think that this whole domain -lends it self excellently to testing via Qemu. Could it be that doing this in -the opposite direction might be a safer approach in the long run even though +lends it self excellently to testing via Qemu. Could it be that doing this in? +the opposite direction might be a safer approach in the long run even though? (significant) more work up-front? -Eg. start by fixing/providing/documenting suitable model(s) -for testing this in Qemu, then implement the patch set based +Eg. start by fixing/providing/documenting suitable model(s)? +for testing this in Qemu, then implement the patch set based? on those models? Thanks, @@ -51,9 +51,5 @@ Knut > > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in -> the body of a message to majordomo@vger.kernel.org -> More majordomo info at http://vger.kernel.org/majordomo-info.html -_______________________________________________ -Linux-nvdimm mailing list -Linux-nvdimm@lists.01.org -https://lists.01.org/mailman/listinfo/linux-nvdimm +> the body of a message to majordomo at vger.kernel.org +> More majordomo info at??http://vger.kernel.org/majordomo-info.html diff --git a/a/content_digest b/N1/content_digest index 8220b5b..d2f10d2 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -15,40 +15,20 @@ "ref\0CAPcyv4iqnz1B00Q3xG-nGrLXdOyB7ditxmwZyotksLFgUqr+jA@mail.gmail.com\0" "ref\05e43818e-8c6b-8be8-23ff-b798633d2a73@deltatee.com\0" "ref\01492381907.25766.49.camel@kernel.crashing.org\0" - "ref\01492381907.25766.49.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org\0" - "From\0Knut Omang <knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>\0" - "Subject\0Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory\0" + "From\0knut.omang@oracle.com (Knut Omang)\0" + "Subject\0[RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory\0" "Date\0Mon, 24 Apr 2017 09:36:37 +0200\0" - "To\0Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>" - Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org> - " Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>\0" - "Cc\0Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>" - Keith Busch <keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> - James E.J. Bottomley <jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> - Martin K. Petersen <martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> - linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> - linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org - Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> - Jerome Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> - Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - linux-scsi <linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - linux-nvdimm <linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org> - Max Gurtovoy <maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> - " Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>\0" "\00:1\0" "b\0" - "On Mon, 2017-04-17 at 08:31 +1000, Benjamin Herrenschmidt wrote:\n" - "> On Sun, 2017-04-16 at 10:34 -0600, Logan Gunthorpe wrote:\n" - "> >\302\240\n" + "On Mon, 2017-04-17@08:31 +1000, Benjamin Herrenschmidt wrote:\n" + "> On Sun, 2017-04-16@10:34 -0600, Logan Gunthorpe wrote:\n" + "> >?\n" "> > On 16/04/17 09:53 AM, Dan Williams wrote:\n" "> > > ZONE_DEVICE allows you to redirect via get_dev_pagemap() to retrieve\n" "> > > context about the physical address in question. I'm thinking you can\n" "> > > hang bus address translation data off of that structure. This seems\n" "> > > vaguely similar to what HMM is doing.\n" - "> >\302\240\n" + "> >?\n" "> > Thanks! I didn't realize you had the infrastructure to look up a device\n" "> > from a pfn/page. That would really come in handy for us.\n" "> \n" @@ -70,18 +50,18 @@ "> \"dma_ops override\" backend. We can have generic code to handle the case\n" "> where devices reside on the same domain, which can deal with switch\n" "> configuration etc... we will need to have iommu specific code to handle\n" - "> the case going through the fabric.\302\240\n" + "> the case going through the fabric.?\n" "> \n" "> Virtualization is a separate can of worms due to how qemu completely\n" "> fakes the MMIO space, we can look into that later.\n" "\n" "My first reflex when reading this thread was to think that this whole domain\n" - "lends it self excellently to testing via Qemu. Could it be that doing this in\302\240\n" - "the opposite direction might be a safer approach in the long run even though\302\240\n" + "lends it self excellently to testing via Qemu. Could it be that doing this in?\n" + "the opposite direction might be a safer approach in the long run even though?\n" "(significant) more work up-front?\n" "\n" - "Eg. start by fixing/providing/documenting suitable model(s)\302\240\n" - "for testing this in Qemu, then implement the patch set based\302\240\n" + "Eg. start by fixing/providing/documenting suitable model(s)?\n" + "for testing this in Qemu, then implement the patch set based?\n" "on those models?\n" "\n" "Thanks,\n" @@ -93,11 +73,7 @@ "> \n" "> --\n" "> To unsubscribe from this list: send the line \"unsubscribe linux-rdma\" in\n" - "> the body of a message to majordomo@vger.kernel.org\n" - "> More majordomo info at\302\240\302\240http://vger.kernel.org/majordomo-info.html\n" - "_______________________________________________\n" - "Linux-nvdimm mailing list\n" - "Linux-nvdimm@lists.01.org\n" - https://lists.01.org/mailman/listinfo/linux-nvdimm + "> the body of a message to majordomo at vger.kernel.org\n" + > More majordomo info at??http://vger.kernel.org/majordomo-info.html -963864d73c79a7b4fa44d2f2f9a66f42cd593e40dc8a1df3ec6142a1b2516fd6 +0925ecf6d010e182f99b2e33f30b4db68465d887e40992dd6e7fa1bdad641b41
diff --git a/a/1.txt b/N2/1.txt index f3baee4..f69cfa1 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,59 +1,59 @@ On Mon, 2017-04-17 at 08:31 +1000, Benjamin Herrenschmidt wrote: > On Sun, 2017-04-16 at 10:34 -0600, Logan Gunthorpe wrote: -> > +> >=C2=A0 > > On 16/04/17 09:53 AM, Dan Williams wrote: > > > ZONE_DEVICE allows you to redirect via get_dev_pagemap() to retrieve > > > context about the physical address in question. I'm thinking you can > > > hang bus address translation data off of that structure. This seems > > > vaguely similar to what HMM is doing. -> > +> >=C2=A0 > > Thanks! I didn't realize you had the infrastructure to look up a device > > from a pfn/page. That would really come in handy for us. -> +>=20 > It does indeed. I won't be able to play with that much for a few weeks > (see my other email) so if you're going to tackle this while I'm away, > can you work with Jerome to make sure you don't conflict with HMM ? -> +>=20 > I really want a way for HMM to be able to layout struct pages over the > GPU BARs rather than in "allocated free space" for the case where the > BAR is big enough to cover all of the GPU memory. -> +>=20 > In general, I'd like a simple & generic way for any driver to ask the > core to layout DMA'ble struct pages over BAR space. I an not convinced > this requires a "p2mem device" to be created on top of this though but > that's a different discussion. -> +>=20 > Of course the actual ability to perform the DMA mapping will be subject > to various restrictions that will have to be implemented in the actual > "dma_ops override" backend. We can have generic code to handle the case > where devices reside on the same domain, which can deal with switch > configuration etc... we will need to have iommu specific code to handle -> the case going through the fabric. -> +> the case going through the fabric.=C2=A0 +>=20 > Virtualization is a separate can of worms due to how qemu completely > fakes the MMIO space, we can look into that later. -My first reflex when reading this thread was to think that this whole domain -lends it self excellently to testing via Qemu. Could it be that doing this in -the opposite direction might be a safer approach in the long run even though +My first reflex when reading this thread was to think that this whole domai= +n +lends it self excellently to testing via Qemu. Could it be that doing this = +in=C2=A0 +the opposite direction might be a safer approach in the long run even thoug= +h=C2=A0 (significant) more work up-front? -Eg. start by fixing/providing/documenting suitable model(s) -for testing this in Qemu, then implement the patch set based +Eg. start by fixing/providing/documenting suitable model(s)=C2=A0 +for testing this in Qemu, then implement the patch set based=C2=A0 on those models? Thanks, Knut -> +>=20 > Cheers, > Ben. -> +>=20 > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org -> More majordomo info at http://vger.kernel.org/majordomo-info.html -_______________________________________________ -Linux-nvdimm mailing list -Linux-nvdimm@lists.01.org -https://lists.01.org/mailman/listinfo/linux-nvdimm +> More majordomo info at=C2=A0=C2=A0http://vger.kernel.org/majordomo-info.h= +tml diff --git a/a/content_digest b/N2/content_digest index 8220b5b..baae344 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -15,89 +15,90 @@ "ref\0CAPcyv4iqnz1B00Q3xG-nGrLXdOyB7ditxmwZyotksLFgUqr+jA@mail.gmail.com\0" "ref\05e43818e-8c6b-8be8-23ff-b798633d2a73@deltatee.com\0" "ref\01492381907.25766.49.camel@kernel.crashing.org\0" - "ref\01492381907.25766.49.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org\0" - "From\0Knut Omang <knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>\0" + "From\0Knut Omang <knut.omang@oracle.com>\0" "Subject\0Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory\0" "Date\0Mon, 24 Apr 2017 09:36:37 +0200\0" - "To\0Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>" - Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org> - " Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>\0" - "Cc\0Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>" - Keith Busch <keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> - James E.J. Bottomley <jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> - Martin K. Petersen <martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> - linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> - linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org - Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> - Jerome Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> - Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - linux-scsi <linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - linux-nvdimm <linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org> - Max Gurtovoy <maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> - " Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>\0" + "To\0Benjamin Herrenschmidt <benh@kernel.crashing.org>" + Logan Gunthorpe <logang@deltatee.com> + " Dan Williams <dan.j.williams@intel.com>\0" + "Cc\0Bjorn Helgaas <helgaas@kernel.org>" + Jason Gunthorpe <jgunthorpe@obsidianresearch.com> + Christoph Hellwig <hch@lst.de> + Sagi Grimberg <sagi@grimberg.me> + James E.J. Bottomley <jejb@linux.vnet.ibm.com> + Martin K. Petersen <martin.petersen@oracle.com> + Jens Axboe <axboe@kernel.dk> + Steve Wise <swise@opengridcomputing.com> + Stephen Bates <sbates@raithlin.com> + Max Gurtovoy <maxg@mellanox.com> + Keith Busch <keith.busch@intel.com> + linux-pci@vger.kernel.org + linux-scsi <linux-scsi@vger.kernel.org> + linux-nvme@lists.infradead.org + linux-rdma@vger.kernel.org + linux-nvdimm <linux-nvdimm@ml01.01.org> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + " Jerome Glisse <jglisse@redhat.com>\0" "\00:1\0" "b\0" "On Mon, 2017-04-17 at 08:31 +1000, Benjamin Herrenschmidt wrote:\n" "> On Sun, 2017-04-16 at 10:34 -0600, Logan Gunthorpe wrote:\n" - "> >\302\240\n" + "> >=C2=A0\n" "> > On 16/04/17 09:53 AM, Dan Williams wrote:\n" "> > > ZONE_DEVICE allows you to redirect via get_dev_pagemap() to retrieve\n" "> > > context about the physical address in question. I'm thinking you can\n" "> > > hang bus address translation data off of that structure. This seems\n" "> > > vaguely similar to what HMM is doing.\n" - "> >\302\240\n" + "> >=C2=A0\n" "> > Thanks! I didn't realize you had the infrastructure to look up a device\n" "> > from a pfn/page. That would really come in handy for us.\n" - "> \n" + ">=20\n" "> It does indeed. I won't be able to play with that much for a few weeks\n" "> (see my other email) so if you're going to tackle this while I'm away,\n" "> can you work with Jerome to make sure you don't conflict with HMM ?\n" - "> \n" + ">=20\n" "> I really want a way for HMM to be able to layout struct pages over the\n" "> GPU BARs rather than in \"allocated free space\" for the case where the\n" "> BAR is big enough to cover all of the GPU memory.\n" - "> \n" + ">=20\n" "> In general, I'd like a simple & generic way for any driver to ask the\n" "> core to layout DMA'ble struct pages over BAR space. I an not convinced\n" "> this requires a \"p2mem device\" to be created on top of this though but\n" "> that's a different discussion.\n" - "> \n" + ">=20\n" "> Of course the actual ability to perform the DMA mapping will be subject\n" "> to various restrictions that will have to be implemented in the actual\n" "> \"dma_ops override\" backend. We can have generic code to handle the case\n" "> where devices reside on the same domain, which can deal with switch\n" "> configuration etc... we will need to have iommu specific code to handle\n" - "> the case going through the fabric.\302\240\n" - "> \n" + "> the case going through the fabric.=C2=A0\n" + ">=20\n" "> Virtualization is a separate can of worms due to how qemu completely\n" "> fakes the MMIO space, we can look into that later.\n" "\n" - "My first reflex when reading this thread was to think that this whole domain\n" - "lends it self excellently to testing via Qemu. Could it be that doing this in\302\240\n" - "the opposite direction might be a safer approach in the long run even though\302\240\n" + "My first reflex when reading this thread was to think that this whole domai=\n" + "n\n" + "lends it self excellently to testing via Qemu. Could it be that doing this =\n" + "in=C2=A0\n" + "the opposite direction might be a safer approach in the long run even thoug=\n" + "h=C2=A0\n" "(significant) more work up-front?\n" "\n" - "Eg. start by fixing/providing/documenting suitable model(s)\302\240\n" - "for testing this in Qemu, then implement the patch set based\302\240\n" + "Eg. start by fixing/providing/documenting suitable model(s)=C2=A0\n" + "for testing this in Qemu, then implement the patch set based=C2=A0\n" "on those models?\n" "\n" "Thanks,\n" "Knut\n" "\n" - "> \n" + ">=20\n" "> Cheers,\n" "> Ben.\n" - "> \n" + ">=20\n" "> --\n" "> To unsubscribe from this list: send the line \"unsubscribe linux-rdma\" in\n" "> the body of a message to majordomo@vger.kernel.org\n" - "> More majordomo info at\302\240\302\240http://vger.kernel.org/majordomo-info.html\n" - "_______________________________________________\n" - "Linux-nvdimm mailing list\n" - "Linux-nvdimm@lists.01.org\n" - https://lists.01.org/mailman/listinfo/linux-nvdimm + "> More majordomo info at=C2=A0=C2=A0http://vger.kernel.org/majordomo-info.h=\n" + tml -963864d73c79a7b4fa44d2f2f9a66f42cd593e40dc8a1df3ec6142a1b2516fd6 +12f7bd3fe09ee3c2b92e660c2fbd1c580967df9cebd332f66b95f25baab2eb55
diff --git a/a/1.txt b/N3/1.txt index f3baee4..dad63ca 100644 --- a/a/1.txt +++ b/N3/1.txt @@ -53,7 +53,3 @@ Knut > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -_______________________________________________ -Linux-nvdimm mailing list -Linux-nvdimm@lists.01.org -https://lists.01.org/mailman/listinfo/linux-nvdimm diff --git a/a/content_digest b/N3/content_digest index 8220b5b..3253032 100644 --- a/a/content_digest +++ b/N3/content_digest @@ -15,29 +15,30 @@ "ref\0CAPcyv4iqnz1B00Q3xG-nGrLXdOyB7ditxmwZyotksLFgUqr+jA@mail.gmail.com\0" "ref\05e43818e-8c6b-8be8-23ff-b798633d2a73@deltatee.com\0" "ref\01492381907.25766.49.camel@kernel.crashing.org\0" - "ref\01492381907.25766.49.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org\0" - "From\0Knut Omang <knut.omang-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>\0" + "From\0Knut Omang <knut.omang@oracle.com>\0" "Subject\0Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory\0" "Date\0Mon, 24 Apr 2017 09:36:37 +0200\0" - "To\0Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>" - Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org> - " Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>\0" - "Cc\0Jens Axboe <axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>" - Keith Busch <keith.busch-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> - James E.J. Bottomley <jejb-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org> - Martin K. Petersen <martin.petersen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> - linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org - Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> - linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org - Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> - Jerome Glisse <jglisse-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> - Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> - linux-scsi <linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - linux-nvdimm <linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org> - Max Gurtovoy <maxg-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org> - " Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>\0" + "To\0Benjamin Herrenschmidt <benh@kernel.crashing.org>" + Logan Gunthorpe <logang@deltatee.com> + " Dan Williams <dan.j.williams@intel.com>\0" + "Cc\0Bjorn Helgaas <helgaas@kernel.org>" + Jason Gunthorpe <jgunthorpe@obsidianresearch.com> + Christoph Hellwig <hch@lst.de> + Sagi Grimberg <sagi@grimberg.me> + James E.J. Bottomley <jejb@linux.vnet.ibm.com> + Martin K. Petersen <martin.petersen@oracle.com> + Jens Axboe <axboe@kernel.dk> + Steve Wise <swise@opengridcomputing.com> + Stephen Bates <sbates@raithlin.com> + Max Gurtovoy <maxg@mellanox.com> + Keith Busch <keith.busch@intel.com> + linux-pci@vger.kernel.org + linux-scsi <linux-scsi@vger.kernel.org> + linux-nvme@lists.infradead.org + linux-rdma@vger.kernel.org + linux-nvdimm <linux-nvdimm@ml01.01.org> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + " Jerome Glisse <jglisse@redhat.com>\0" "\00:1\0" "b\0" "On Mon, 2017-04-17 at 08:31 +1000, Benjamin Herrenschmidt wrote:\n" @@ -94,10 +95,6 @@ "> --\n" "> To unsubscribe from this list: send the line \"unsubscribe linux-rdma\" in\n" "> the body of a message to majordomo@vger.kernel.org\n" - "> More majordomo info at\302\240\302\240http://vger.kernel.org/majordomo-info.html\n" - "_______________________________________________\n" - "Linux-nvdimm mailing list\n" - "Linux-nvdimm@lists.01.org\n" - https://lists.01.org/mailman/listinfo/linux-nvdimm + "> More majordomo info at\302\240\302\240http://vger.kernel.org/majordomo-info.html" -963864d73c79a7b4fa44d2f2f9a66f42cd593e40dc8a1df3ec6142a1b2516fd6 +9f332b3b722706f2a43ca921df9266e0ce0be0ac16d5d7fd3b04203223953746
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.