All of lore.kernel.org
 help / color / mirror / Atom feed
From: axboe@kernel.dk (Jens Axboe)
Subject: [PATCH v2] nvme: temporary fix for Apple controller reset
Date: Tue, 1 Dec 2015 13:21:14 -0700	[thread overview]
Message-ID: <565E013A.10105@kernel.dk> (raw)
In-Reply-To: <2b5655ec98dda469696608bf34344e5a@localhost>

On 12/01/2015 01:05 PM, 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?
>
> I do not know what the OSX driver does. Apple is of absolutely no help
> whatsoever.

That's unfortunately not news... I used to run linux on a macbook, and 
some of the ahci based SSDs would randomly hang if msi interrupts were 
used. We had to quirk around that too, and as far as I know, nobody got 
any response from Apple on that issue either.

> 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.

As per your other message on the device being single queue, then that 
does make the case more believable. I guess if you guys are fine with 
it, it's better to have it in.


-- 
Jens Axboe

      parent reply	other threads:[~2015-12-01 20:21 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
2015-12-01 20:21       ` Jens Axboe [this message]

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=565E013A.10105@kernel.dk \
    --to=axboe@kernel.dk \
    /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.