All of lore.kernel.org
 help / color / mirror / Atom feed
From: jvbockel@gmail.com (John Van Bockel)
Subject: Two M.2 NVMe drives with same NQN, one gets removed
Date: Sun, 18 Nov 2018 13:08:13 -0600	[thread overview]
Message-ID: <CAGmwwfeTw=jvOt1U_hgFJktor1R4HmYL6_pxGc-==AbAHDQCGA@mail.gmail.com> (raw)
In-Reply-To: <20181117013337.GA23062@localhost.localdomain>

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

  reply	other threads:[~2018-11-18 19:08 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-17  0:17 Two M.2 NVMe drives with same NQN, one gets removed John Van Bockel
2018-11-17  1:33 ` Keith Busch
2018-11-18 19:08   ` John Van Bockel [this message]
     [not found]   ` <CAGmwwfc=g+4h12qMBvRVJoE66Z70kzzfkabjyxLC=d7LZp627A@mail.gmail.com>
2018-11-19 17:00     ` Keith Busch
2018-11-21 21:19       ` John Van Bockel
2018-11-26 13:38 James Dingwall
2018-11-26 15:31 ` Keith Busch
2018-11-27  7:54   ` Christoph Hellwig
2018-11-27 10:25     ` James Dingwall
2018-11-27 15:01       ` Keith Busch
2018-11-30 11:50         ` James Dingwall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGmwwfeTw=jvOt1U_hgFJktor1R4HmYL6_pxGc-==AbAHDQCGA@mail.gmail.com' \
    --to=jvbockel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.