All of lore.kernel.org
 help / color / mirror / Atom feed
From: guenther@tum.de (Stephan Günther)
Subject: [PATCH v2] nvme: temporary fix for Apple controller reset
Date: Tue, 1 Dec 2015 21:10:24 +0100	[thread overview]
Message-ID: <d422150a034fbe5fa435a8c8b67ab5e0@localhost> (raw)
In-Reply-To: <2b5655ec98dda469696608bf34344e5a@localhost>

Sorry for the addition regarding testing (see below).

On 2015/December/01 09:05, Stephan G?nther wrote:
> On 2015/December/01 12:56, Jens Axboe wrote:
> > On 12/01/2015 12:46 PM, Stephan G?nther wrote:
> > >The patch below has been reviewed by Christoph and reported to work.
> > >However, there is still no sign that it will be applied to linux-4.4.
> > >
> > >Please either undo commit c74dc7801d515d01847fd5cf2b472489fa5717b1,
> > >which added the PCI ID of the Apple controller, or merge the patch below
> > >asap.
> > >
> > >
> > >Currently, the driver will make that controller destroy data!
> > 
> > Honestly, I'd rather revert the pci id addition, unless there's conclusive
> > evidence that limiting the (per queue) depth to 2 really does fix the issue.
> 
> Wes Cilldhaire tested the patch (his answer is in that thread) - as I
> did the past 3 weeks ago as I'm running solely Linux on that broken 
> MacBook.
> 
> > Is this what the OSX driver does? What testing was done to ascertain that 2
> > is the magic number? Does it just make it harder to hit, or does it really
> > fix it?

Any number larger than 2 immediately triggered the problem for me. With 
per-queue depth = 2 it did not happen for 3 weeks.

Moreover, that Apple controller seems to have a single queue...

Best,
Stephan

> 
> I do not know what the OSX driver does. Apple is of absolutely no help
> whatsoever.
> 
> But without that patch `mkfs btrfs` immediately fails. Even `partprobe
> /dev/nvme0n1` will reset the controller (the latter one without data
> loss).
> 
> As I am running a btrfs on a luks container for 3 weeks with that patch,
> it *does* work. Performance is, obviously, not the best one I have seen.
> But given the circumstances I cannot complain at all.
> 
> 
> So again: please either revert the previous patch and leave it to the
> more interested individuals to try it (probably slowing down Linux
> support for that MacBook as not detecting the hard-soldered disk is
> quite a blocker), or merge that hotfix until we find a better solution.
> 
> With 4.5 that may even become a quirk.
> 
> 
> Best,
> Stephan

  reply	other threads:[~2015-12-01 20:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-22  2:28 [PATCH v2] nvme: temporary fix for Apple controller reset Stephan Günther
2015-11-22  8:56 ` Christoph Hellwig
2015-11-25  0:21   ` Wes Cilldhaire
2015-12-01 19:46 ` Stephan Günther
2015-12-01 19:56   ` Jens Axboe
2015-12-01 20:05     ` Stephan Günther
2015-12-01 20:10       ` Stephan Günther [this message]
2015-12-01 20:21       ` Jens Axboe

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=d422150a034fbe5fa435a8c8b67ab5e0@localhost \
    --to=guenther@tum.de \
    /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.