Two M.2 NVMe drives with same NQN, one gets removed

Two M.2 NVMe drives with same NQN, one gets removed

[James Dingwall]

Hi,

We have also encountered this issue but the devices have a customised
firmware from Lenovo:

# nvme id-ctrl /dev/nvme0
NVME Identify Controller:
vid : 0x8086
ssvid : 0x8086
sn : BTHH82250N1X1P0E
mn : INTEL SSDPEKKF010T8L
fr : L08P

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803692?comments=all

I tried to force install the Intel firmware but that did not work.  I
was fobbed off by Lenovo support with a 'we don't support Linux' even
after pointing out the upstream Intel fix.  Is there any possibility
of being able to work around this in the nvme code?

Thanks,
James

Two M.2 NVMe drives with same NQN, one gets removed

[Keith Busch]

On Mon, Nov 26, 2018@01:38:39PM +0000, James Dingwall wrote:
> Hi,
> 
> We have also encountered this issue but the devices have a customised
> firmware from Lenovo:
> 
> # nvme id-ctrl /dev/nvme0
> NVME Identify Controller:
> vid : 0x8086
> ssvid : 0x8086
> sn : BTHH82250N1X1P0E
> mn : INTEL SSDPEKKF010T8L
> fr : L08P
> 
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1803692?comments=all
> 
> I tried to force install the Intel firmware but that did not work.  I
> was fobbed off by Lenovo support with a 'we don't support Linux' even
> after pointing out the upstream Intel fix.  Is there any possibility
> of being able to work around this in the nvme code?
> 
> Thanks,
> James

Hi James,

According to the resolution discussion here:

  https://downloadcenter.intel.com/download/28320/Known-Issue-Intel-SSD-760p-Pro-7600p-Series-SubNQN-Conflict-on-Linux

  "
  If you purchased your Intel? SSD from an OEM, your firmware version may
  have a different naming. Contact your local OEM representative for
  latest firmware revisions.
  "

Sounds like Lenovo will need to merge the Intel update into their
specific firmware if they haven't already done so.

Thansk,
Keith

Two M.2 NVMe drives with same NQN, one gets removed

[Christoph Hellwig]

On Mon, Nov 26, 2018@08:31:11AM -0700, Keith Busch wrote:
> According to the resolution discussion here:
> 
>   https://downloadcenter.intel.com/download/28320/Known-Issue-Intel-SSD-760p-Pro-7600p-Series-SubNQN-Conflict-on-Linux
> 
>   "
>   If you purchased your Intel? SSD from an OEM, your firmware version may
>   have a different naming. Contact your local OEM representative for
>   latest firmware revisions.
>   "
> 
> Sounds like Lenovo will need to merge the Intel update into their
> specific firmware if they haven't already done so.

OEMs are notoriously bad in picking up firmware fixes.  If the problems
with this drive persist we should probably add a quick that ignores the
drive provided NQN and build up one from based on the legacy
model/serial number algorithm instead.

Two M.2 NVMe drives with same NQN, one gets removed

[James Dingwall]

Hi,
On Mon, Nov 26, 2018@11:54:27PM -0800, Christoph Hellwig wrote:
> On Mon, Nov 26, 2018@08:31:11AM -0700, Keith Busch wrote:
> > According to the resolution discussion here:
> > 
> >   https://downloadcenter.intel.com/download/28320/Known-Issue-Intel-SSD-760p-Pro-7600p-Series-SubNQN-Conflict-on-Linux
> > 
> >   "
> >   If you purchased your Intel? SSD from an OEM, your firmware version may
> >   have a different naming. Contact your local OEM representative for
> >   latest firmware revisions.
> >   "
> > 
> > Sounds like Lenovo will need to merge the Intel update into their
> > specific firmware if they haven't already done so.
> 
> OEMs are notoriously bad in picking up firmware fixes.  If the problems
> with this drive persist we should probably add a quick that ignores the
> drive provided NQN and build up one from based on the legacy
> model/serial number algorithm instead.

Would something like this be the way to go if an appropriate entry is
created in the nvme_id_table in pci.c?  The example subnqn shown in
http://lists.infradead.org/pipermail/linux-nvme/2018-November/021154.html
looks like the fallback entry so I suppose the firmware fix has been to
just blank the relevant field.  (Should 2014.08.org be 2014-08.org
in core.c when generating the fake name?)

Thanks,
James

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 559d567693b8..d4ace74237d9 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2076,10 +2076,12 @@ static void nvme_init_subnqn(struct nvme_subsystem *subsys, struct nvme_ctrl *ct
 	size_t nqnlen;
 	int off;
 
-	nqnlen = strnlen(id->subnqn, NVMF_NQN_SIZE);
-	if (nqnlen > 0 && nqnlen < NVMF_NQN_SIZE) {
-		strlcpy(subsys->subnqn, id->subnqn, NVMF_NQN_SIZE);
-		return;
+	if(!(ctrl->quirks & NVME_QUIRK_IGNORE_DEV_SUBNQN)) {
+		nqnlen = strnlen(id->subnqn, NVMF_NQN_SIZE);
+		if (nqnlen > 0 && nqnlen < NVMF_NQN_SIZE) {
+			strlcpy(subsys->subnqn, id->subnqn, NVMF_NQN_SIZE);
+			return;
+		}
 	}
 
 	if (ctrl->vs >= NVME_VS(1, 2, 1))
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index cee79cb388af..a07155c05328 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -90,6 +90,11 @@ enum nvme_quirks {
 	 * Set MEDIUM priority on SQ creation
 	 */
 	NVME_QUIRK_MEDIUM_PRIO_SQ		= (1 << 7),
+
+	/*
+	 * Ignore device provided subnqn.
+	 */
+	NVME_QUIRK_IGNORE_DEV_SUBNQN		= (1 << 8),
 };
 
 /*

Two M.2 NVMe drives with same NQN, one gets removed

[Keith Busch]

On Tue, Nov 27, 2018@02:25:54AM -0800, James Dingwall wrote:
> Hi,
> On Mon, Nov 26, 2018@11:54:27PM -0800, Christoph Hellwig wrote:
> > On Mon, Nov 26, 2018@08:31:11AM -0700, Keith Busch wrote:
> > > According to the resolution discussion here:
> > > 
> > >   https://downloadcenter.intel.com/download/28320/Known-Issue-Intel-SSD-760p-Pro-7600p-Series-SubNQN-Conflict-on-Linux
> > > 
> > >   "
> > >   If you purchased your Intel? SSD from an OEM, your firmware version may
> > >   have a different naming. Contact your local OEM representative for
> > >   latest firmware revisions.
> > >   "
> > > 
> > > Sounds like Lenovo will need to merge the Intel update into their
> > > specific firmware if they haven't already done so.
> > 
> > OEMs are notoriously bad in picking up firmware fixes.  If the problems
> > with this drive persist we should probably add a quick that ignores the
> > drive provided NQN and build up one from based on the legacy
> > model/serial number algorithm instead.
> 
> Would something like this be the way to go if an appropriate entry is
> created in the nvme_id_table in pci.c?  The example subnqn shown in
> http://lists.infradead.org/pipermail/linux-nvme/2018-November/021154.html
> looks like the fallback entry so I suppose the firmware fix has been to
> just blank the relevant field.  (Should 2014.08.org be 2014-08.org
> in core.c when generating the fake name?)
> 
> Thanks,
> James

Looks correct, and just needs the nvme_id_table updated as you
mentioned. I also recommend skipping the NVME_VS(1, 2, 1) check if the
quirk is set so we're not warning users.


> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 559d567693b8..d4ace74237d9 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -2076,10 +2076,12 @@ static void nvme_init_subnqn(struct nvme_subsystem *subsys, struct nvme_ctrl *ct
>  	size_t nqnlen;
>  	int off;
>  
> -	nqnlen = strnlen(id->subnqn, NVMF_NQN_SIZE);
> -	if (nqnlen > 0 && nqnlen < NVMF_NQN_SIZE) {
> -		strlcpy(subsys->subnqn, id->subnqn, NVMF_NQN_SIZE);
> -		return;
> +	if(!(ctrl->quirks & NVME_QUIRK_IGNORE_DEV_SUBNQN)) {
> +		nqnlen = strnlen(id->subnqn, NVMF_NQN_SIZE);
> +		if (nqnlen > 0 && nqnlen < NVMF_NQN_SIZE) {
> +			strlcpy(subsys->subnqn, id->subnqn, NVMF_NQN_SIZE);
> +			return;
> +		}
>  	}
>  
>  	if (ctrl->vs >= NVME_VS(1, 2, 1))
> diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
> index cee79cb388af..a07155c05328 100644
> --- a/drivers/nvme/host/nvme.h
> +++ b/drivers/nvme/host/nvme.h
> @@ -90,6 +90,11 @@ enum nvme_quirks {
>  	 * Set MEDIUM priority on SQ creation
>  	 */
>  	NVME_QUIRK_MEDIUM_PRIO_SQ		= (1 << 7),
> +
> +	/*
> +	 * Ignore device provided subnqn.
> +	 */
> +	NVME_QUIRK_IGNORE_DEV_SUBNQN		= (1 << 8),
>  };
>  
>  /*

Two M.2 NVMe drives with same NQN, one gets removed

[James Dingwall]

On Tue, Nov 27, 2018@08:01:02AM -0700, Keith Busch wrote:
> On Tue, Nov 27, 2018@02:25:54AM -0800, James Dingwall wrote:
> > Hi,
> > On Mon, Nov 26, 2018@11:54:27PM -0800, Christoph Hellwig wrote:
> > > On Mon, Nov 26, 2018@08:31:11AM -0700, Keith Busch wrote:
> > > > According to the resolution discussion here:
> > > > 
> > > >   https://downloadcenter.intel.com/download/28320/Known-Issue-Intel-SSD-760p-Pro-7600p-Series-SubNQN-Conflict-on-Linux
> > > > 
> > > >   "
> > > >   If you purchased your Intel? SSD from an OEM, your firmware version may
> > > >   have a different naming. Contact your local OEM representative for
> > > >   latest firmware revisions.
> > > >   "
> > > > 
> > > > Sounds like Lenovo will need to merge the Intel update into their
> > > > specific firmware if they haven't already done so.
> > > 
> > > OEMs are notoriously bad in picking up firmware fixes.  If the problems
> > > with this drive persist we should probably add a quick that ignores the
> > > drive provided NQN and build up one from based on the legacy
> > > model/serial number algorithm instead.
> > 
> > Would something like this be the way to go if an appropriate entry is
> > created in the nvme_id_table in pci.c?  The example subnqn shown in
> > http://lists.infradead.org/pipermail/linux-nvme/2018-November/021154.html
> > looks like the fallback entry so I suppose the firmware fix has been to
> > just blank the relevant field.  (Should 2014.08.org be 2014-08.org
> > in core.c when generating the fake name?)
> > 
> > Thanks,
> > James
> 
> Looks correct, and just needs the nvme_id_table updated as you
> mentioned. I also recommend skipping the NVME_VS(1, 2, 1) check if the
> quirk is set so we're not warning users.
> 
I have tested this patch in a build of the Ubuntu 4.15.0-39-generic
kernel adjusted only for a strncpy / strlcpy for the change in core.c.
I have moved the NVME_VS(1, 2, 1) if the quirk is set.  I'm not sure
how to restrict the nvme_id_table entry to specific firmware revisions
but perhaps that doesn't matter if (at least in this case) the fixed
firmware no longer supplies a value.

james at nvmetest:~$ cat /sys/class/block/nvme[01]n1/device/subsysnqn
nqn.2014.08.org.nvmexpress:80868086BTHH82250N1X1P0E    INTEL SSDPEKKF010T8L                    
nqn.2014.08.org.nvmexpress:80868086BTHH82250N261P0E    INTEL SSDPEKKF010T8L                    
james at nvmetest:~$ uname -r
4.15.0-39-generic

I have put the patch as a single commit on nvme-quirk-subnqn of
https://github.com/JKDingwall/linux.git.  I can split it if it makes
sense.

Thanks,
James


commit e6a9e9cc96aefbf4c984844f19b23095f225d5c0
Author: James Dingwall <james at dingwall.me.uk>
Date:   Tue Nov 27 16:11:23 2018 +0000

    nvme: introduce NVME_QUIRK_IGNORE_DEV_SUBNQN
    
    If a device provides an NQN it is expected to be globally unique.
    Unfortunately some firmware revisions for Intel 760p/Pro 7600p devices did
    not satisfy this requirement.  In these circumstances if a system has >1
    affected device then only one device is enabled.  If this quirk is enabled
    then the device supplied subnqn is ignored and we fallback to generating
    one as if the field was empty.  In this case we also suppress the version
    check so we don't print a warning when the quirk is enabled.
    
    Signed-off-by: James Dingwall <james at dingwall.me.uk>

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 559d567693b8..54bd23bba17d 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2076,14 +2076,16 @@ static void nvme_init_subnqn(struct nvme_subsystem *subsys, struct nvme_ctrl *ct
 	size_t nqnlen;
 	int off;
 
-	nqnlen = strnlen(id->subnqn, NVMF_NQN_SIZE);
-	if (nqnlen > 0 && nqnlen < NVMF_NQN_SIZE) {
-		strlcpy(subsys->subnqn, id->subnqn, NVMF_NQN_SIZE);
-		return;
-	}
+	if(!(ctrl->quirks & NVME_QUIRK_IGNORE_DEV_SUBNQN)) {
+		nqnlen = strnlen(id->subnqn, NVMF_NQN_SIZE);
+		if (nqnlen > 0 && nqnlen < NVMF_NQN_SIZE) {
+			strlcpy(subsys->subnqn, id->subnqn, NVMF_NQN_SIZE);
+			return;
+		}
 
-	if (ctrl->vs >= NVME_VS(1, 2, 1))
-		dev_warn(ctrl->device, "missing or invalid SUBNQN field.\n");
+		if (ctrl->vs >= NVME_VS(1, 2, 1))
+			dev_warn(ctrl->device, "missing or invalid SUBNQN field.\n");
+	}
 
 	/* Generate a "fake" NQN per Figure 254 in NVMe 1.3 + ECN 001 */
 	off = snprintf(subsys->subnqn, NVMF_NQN_SIZE,
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index cee79cb388af..a07155c05328 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -90,6 +90,11 @@ enum nvme_quirks {
 	 * Set MEDIUM priority on SQ creation
 	 */
 	NVME_QUIRK_MEDIUM_PRIO_SQ		= (1 << 7),
+
+	/*
+	 * Ignore device provided subnqn.
+	 */
+	NVME_QUIRK_IGNORE_DEV_SUBNQN		= (1 << 8),
 };
 
 /*
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index c33bb201b884..f05cdf4802f7 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2696,6 +2696,8 @@ static const struct pci_device_id nvme_id_table[] = {
 	{ PCI_VDEVICE(INTEL, 0xf1a5),	/* Intel 600P/P3100 */
 		.driver_data = NVME_QUIRK_NO_DEEPEST_PS |
 				NVME_QUIRK_MEDIUM_PRIO_SQ },
+	{ PCI_VDEVICE(INTEL, 0xf1a6),	/* Intel 760p/Pro 7600p */
+		.driver_data = NVME_QUIRK_IGNORE_DEV_SUBNQN, },
 	{ PCI_VDEVICE(INTEL, 0x5845),	/* Qemu emulated controller */
 		.driver_data = NVME_QUIRK_IDENTIFY_CNS, },
 	{ PCI_DEVICE(0x1bb1, 0x0100),   /* Seagate Nytro Flash Storage */

Two M.2 NVMe drives with same NQN, one gets removed

[John Van Bockel]

Hi Keith,

I updated to version 004X of the 760p firmware and all appears to be working.
Thanks a bunch for steering me in the right direction.  Some results follow, in
case you're interested.

Thanks
jvbockel at gmail.com

# dmesg | grep -i nvme
[    3.475727] nvme nvme0: pci function 0000:72:00.0
[    3.475798] nvme nvme1: pci function 0000:73:00.0
[    3.585705] nvme nvme1: missing or invalid SUBNQN field.
[    3.588561]  nvme0n1: p1 p2
[    3.688492] nvme nvme0: missing or invalid SUBNQN field.
[    3.690815]  nvme1n1: p1 p2 p3 p4

# nvme list
Node             SN                   Model
        Namespace Usage                      Format           FW Rev
---------------- --------------------
---------------------------------------- ---------
-------------------------- ---------------- --------
/dev/nvme0n1     BTHH81850BX31P0E     INTEL SSDPEKKW010T8
        1           1.02  TB /   1.02  TB    512   B +  0 B   004X
/dev/nvme1n1     BTHH81850C8W1P0E     INTEL SSDPEKKW010T8
        1           1.02  TB /   1.02  TB    512   B +  0 B   004X

# nvme list-subsys
nvme-subsys0 - NQN=nqn.2014.08.org.nvmexpress:80868086BTHH81850BX31P0E
   INTEL SSDPEKKW010T8
\
 +- nvme1 pcie 0000:73:00.0
nvme-subsys1 - NQN=nqn.2014.08.org.nvmexpress:80868086BTHH81850C8W1P0E
   INTEL SSDPEKKW010T8
\
 +- nvme0 pcie 0000:72:00.0


On Mon, Nov 19, 2018@11:04 AM Keith Busch <keith.busch@intel.com> wrote:
>
> On Sun, Nov 18, 2018@10:55:11AM -0800, John Van Bockel wrote:
> > That's good news and very much appreciate the information and all
> > that you do for the open source community.  Is this an update for the
> > 760p NVMe drives or instead a UEFI update for the NUC8i7HVK?
> > Either way, good news.  Just wondering which I'm keeping an eye out
> > for.
>
> It's a 760p update, and looks like it was released earlier this month:
>
>   https://downloadcenter.intel.com/download/28320/Known-Issue-Intel-SSD-760p-Pro-7600p-Series-SubNQN-Conflict-on-Linux
>
> Sorry I missed that update, otherwise I could have sent you that link
> last week.

Two M.2 NVMe drives with same NQN, one gets removed

[Keith Busch]

On Sun, Nov 18, 2018@10:55:11AM -0800, John Van Bockel wrote:
> That's good news and very much appreciate the information and all 
> that you do for the open source community.  Is this an update for the 
> 760p NVMe drives or instead a UEFI update for the NUC8i7HVK?  
> Either way, good news.  Just wondering which I'm keeping an eye out 
> for.  

It's a 760p update, and looks like it was released earlier this month:

  https://downloadcenter.intel.com/download/28320/Known-Issue-Intel-SSD-760p-Pro-7600p-Series-SubNQN-Conflict-on-Linux

Sorry I missed that update, otherwise I could have sent you that link
last week.

Two M.2 NVMe drives with same NQN, one gets removed

[John Van Bockel]

Hi Keith,

That's good news and very much appreciate the information and all
that you do for the open source community.  Is this an update for the
760p NVMe drives or instead a UEFI update for the NUC8i7HVK?
Either way, good news.  Just wondering which I'm keeping an eye out
for.

Other than this minor problem, I sure am liking this NUC.  I'm finding
that contemporary versions of Linux work very nicely, even the Radeon
Vega M GPU.

Thanks again.  I'll patiently keep an eye out for the FW update.  Easily
worked around for the moment.

Cheers
jvbockel at gmail.com

On Fri, Nov 16, 2018@7:37 PM Keith Busch <keith.busch@intel.com> wrote:
>
> On Fri, Nov 16, 2018@06:17:22PM -0600, John Van Bockel wrote:
> > Hi,
> >
> > I have an Intel NUC8i7HVK mini-computer and a pair of Intel 760p 1TB M.2 NVMe
> > SSD drives.  With Fedora 29 and Ubuntu 18.10 (both 4.18 kernels), the
> > nvme kernel
> > module insists upon disabling one of the two NVMe drives when it notices that
> > both have been assigned the same NVMe Qualified Name (NQN).  The one that gets
> > removed by the nvme module is not always the same.  Whichever remains enabled
> > performs perfectly.
> >
> > [root at NUCnFutz ~]# dmesg | grep -i nvme
> >
> > [    3.372662] nvme nvme0: pci function 0000:72:00.0
> > [    3.372710] nvme nvme1: pci function 0000:73:00.0
> > [    3.484113]  nvme0n1: p1 p2 p3 p4
> > [    3.584531] nvme nvme1: ignoring ctrl due to duplicate subnqn
> > (nqn.2017-12.org.nvmexpress:uuid:11111111-2222-3333-4444-555555555555).
> > [    3.584533] nvme nvme1: Removing after probe failure status: -22
>
> This is a firmware bug. The maker is aware and have a fix undergoing
> validation. I am not sure what is gating its release so I've pinged the
> management for an update and will respond as soon as I hear a reply.
>
> Thanks,
> Keith

Two M.2 NVMe drives with same NQN, one gets removed

[Keith Busch]

On Fri, Nov 16, 2018@06:17:22PM -0600, John Van Bockel wrote:
> Hi,
> 
> I have an Intel NUC8i7HVK mini-computer and a pair of Intel 760p 1TB M.2 NVMe
> SSD drives.  With Fedora 29 and Ubuntu 18.10 (both 4.18 kernels), the
> nvme kernel
> module insists upon disabling one of the two NVMe drives when it notices that
> both have been assigned the same NVMe Qualified Name (NQN).  The one that gets
> removed by the nvme module is not always the same.  Whichever remains enabled
> performs perfectly.
> 
> [root at NUCnFutz ~]# dmesg | grep -i nvme
> 
> [    3.372662] nvme nvme0: pci function 0000:72:00.0
> [    3.372710] nvme nvme1: pci function 0000:73:00.0
> [    3.484113]  nvme0n1: p1 p2 p3 p4
> [    3.584531] nvme nvme1: ignoring ctrl due to duplicate subnqn
> (nqn.2017-12.org.nvmexpress:uuid:11111111-2222-3333-4444-555555555555).
> [    3.584533] nvme nvme1: Removing after probe failure status: -22

This is a firmware bug. The maker is aware and have a fix undergoing
validation. I am not sure what is gating its release so I've pinged the
management for an update and will respond as soon as I hear a reply.

Thanks,
Keith

Two M.2 NVMe drives with same NQN, one gets removed

[John Van Bockel]

Hi,

I have an Intel NUC8i7HVK mini-computer and a pair of Intel 760p 1TB M.2 NVMe
SSD drives.  With Fedora 29 and Ubuntu 18.10 (both 4.18 kernels), the
nvme kernel
module insists upon disabling one of the two NVMe drives when it notices that
both have been assigned the same NVMe Qualified Name (NQN).  The one that gets
removed by the nvme module is not always the same.  Whichever remains enabled
performs perfectly.

[root at NUCnFutz ~]# dmesg | grep -i nvme

[    3.372662] nvme nvme0: pci function 0000:72:00.0
[    3.372710] nvme nvme1: pci function 0000:73:00.0
[    3.484113]  nvme0n1: p1 p2 p3 p4
[    3.584531] nvme nvme1: ignoring ctrl due to duplicate subnqn
(nqn.2017-12.org.nvmexpress:uuid:11111111-2222-3333-4444-555555555555).
[    3.584533] nvme nvme1: Removing after probe failure status: -22

If I disable one in the UEFI BIOS, the other works perfectly with Linux.  It
does not matter which I disable, the enabled drive works perfectly.  Windows 10
has no trouble performing I/O against both drives when both are enabled.  I've
tried various combinations of settings in the UEFI to see if I could alter the
result of both being given the same NQN.  Firware versions for both
the NUC8i7hvk
and 760p SSD drives are at the latest 51 and 004C versions, respectively.

With the first M.2 slot enabled in UEFI, "nvme list" & "nvme list-subsys" yield:
/dev/nvme0n1 BTHH81850C8W1P0E INTEL SSDPEKKW010T8 1 1.02 TB / 1.02 TB
512 B + 0 B 004C
nvme-subsys0 - NQN=nqn.2017-12.org.nvmexpress:uuid:11111111-2222-3333-4444-555555555555
+- nvme0 pcie 0000:72:00.0

With the second M.2 slot enabled, "nvme list" & "nvme list-susbsys" produce:
/dev/nvme0n1 BTHH81850BX31P0E INTEL SSDPEKKW010T8 1 1.02 TB / 1.02 TB
512 B + 0 B 004C
nvme-subsys0 - NQN=nqn.2017-12.org.nvmexpress:uuid:11111111-2222-3333-4444-555555555555
+- nvme0 pcie 0000:73:00.0

I did have one boot in which both remained enabled.  Slot one was given a device
name of /dev/nvme0n1 with a 0000:72:00.0 path and slot two was given the
/dev/nvme0n2 name with its 0000:73:00.0 path.  I was excited by this result but
was unable to repeat the result.  I wish I had thought to see if both continued
to share the same NQN in that one fleeting success.

Intel regards the combination of NUC8i7HVK and 2TB 760p NVMe drives as
supported.
Mine are the 1TB version of the 760p drives, so I am deviating ever so slightly.
Also, Intel doesn't claim any responsibility for running Linux on the
NUCs and says
to contact the distribution.  The problem seems to be independent of
distribution,
having tried both Fedora 29 (kernel 4.18.16 & 4.18.18) and Ubuntu
18.10 (4.18.?).

I do not know how the NQN is being assigned to the drives.  Whether
the UEFI BIOS
is to blame or is instead being assigned by a Linux kernel module.  If this is
instead a defect in the UEFI, please let me know and I'll move on to communicate
with Intel Support.

Thanks
jvbockel at gmail.com