[PATCH v2] nvme: temporary fix for Apple controller reset
Jens Axboe
axboe at kernel.dk
Tue Dec 1 12:21:14 PST 2015
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
More information about the Linux-nvme
mailing list