-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to get NVMe working on MBP 13,1 #9
Comments
Booting a live or installation media, enabling the NVMe workaround and then installing it to disk is definitely the right approach. I installed Debian the same way on my MBP. Regarding the black screen all I can suggest is:
|
You will need to apply the NVMe workaround also in the installed system, before attempting to mount the rootfs. I just installed archlinux and added a hook to mkinitcpio that applies the NVM workaround:
I don't use ubuntu, so I'm not familiar how to apply this there. |
Good news regarding NVMe: Starting from Linux 4.11 all these workarounds to get it working, won't be neccessary anymore. 😄 |
@Dunedan Did you install Linux on the Apple SSD or are you booting from external storage? |
I'm not Dunedan, but I booted linux-4.10 from a USB installation media, manually applied the NVMe workaround, installed to the Apple SSD, set up the workaround above in the initrd to allow booting 4.10 off the SSD. When 4.11 is released and available by your distro, the initrd hook becomes unnecessary. When your installation media contains 4.11, it should work out of the box. |
@christophgysin Thanks. I installed it.
I plan on looking at that and maybe create a patch if that's the culprit. Has anyone else encountered this? |
Yes, I've seen that too. |
Me too. I have that pretty regularly nowadays actually. Haven't had that problem 1-2 months ago, which lead me to the conclusion that it's not related to that workaround for the other MacBooks, but maybe it is anyway. One thing to note: For me it happens only during boot. Once access to the NVMe controller works it'll continue to work the whole time the MBP stays on. A wild idea I had this morning is that it could be related to not issuing the proper vendor specific command on shutdown, Apple apparently sends (cb22/macbook12-spi-driver#2 (comment)). In any case keep in mind that the quoted kernel source is just a workaround and no proper solution. |
@Dunedan I did the fix and it seems to work, It's the same workaround, but it seems to work as I restarted 10 times already and it doesn't appear anymore.
Hopefully it won't appear anymore. |
Unfortunately, it has appeared. It seems I had a lucky streak those 10 times. |
This post contains a link to download a script called isorespin.sh which can modify an Ubuntu/Mint ISO file and update the kernel to 4.11: http://linuxiumcomau.blogspot.com/2017/04/creating-personalized-ubuntu-mint-and.html?m=1 It makes it easy to resolve the issue of not being able to see the NVMe SSD. Now I just need to figure out how to get the built-in keyboard and track pad working... |
@tudorbarascu Regarding the issue with the NVMe controller not working every boot, I have no solution, but at least some new insights. The patch from #1 (comment) makes the problem way, way worse. I don't know how and why, but I thought it's information worth sharing. Without the patch it only happens rarely, but with it it happened most of the time for me. Was a real pain in the ass to get it properly booted with it. |
I'm wondering if there's any progress on this NVMe problem on boot (and I guess suspend/resume problem is perhaps the same issue?). |
To document the link to the Bugzilla case you opened here as well: https://bugzilla.kernel.org/show_bug.cgi?id=196503 |
Thanks @Dunedan. I've just upgraded to systemd 234 on Arch Linux earlier today, and since then this problem has got worse somehow. In fact, none of my attempts to boot was successful when the initramfs was built with systemd hooks. I'm not entirely sure why. |
I'm running systemd 234 since a few days as well, but I saw no change in the behavior. |
It's probably a systemd problem, and has nothing to do with whether NVMe initialises correctly at boot. |
Hi everyone,
On 28/07/17 01:16, Peter Y. Chuang wrote:
It's probably a systemd problem <https://bugs.archlinux.org/task/54825>, and has nothing to do with whether NVMe initialises correctly at boot.
Have you given a try on system V or OpenRC system ?
hth,Jerome
…
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIFYLOkSXzbIf2cxsCVl1FZZPHFapaiGks5sSP4igaJpZM4M6cIT>.
--
Jerome BENOIT, Ph.D. | jgmbenoit-at+rezozer*dot_net
http://www.rezozer.net/
|
@Dunedan what seems strange to me, now that I've got around the systemd problem (and playing with linux-next at the moment), is that the delay in finding my encrypted partition is very consistent: exactly 1 minute. I'm having 100% boot success rate, but most of the time I have to wait for exactly a minute before I can enter my passphrase. |
I up to one of your previous comments didn't even bother to wait. Once I encountered a timeout I'd simply reboot under the assumption that it wouldn't work otherwise. Based on your comments I tried out leaving it after the timeout occurs and indeed, I then just have to wait another 30 or 60 seconds until it works. I'll continue to observe if that's always the case. |
Output of
Perhaps something to do with this, but not sure what that means. |
@peterychuang Btw., which model do you have? I thought you had mentioned you had a 13,3 somewhere, but can't find it right now. The reason I'm asking is that my 13,3 has a Samsung controller, so if you have the Apple controller, then my assumption about the controller being model related is wrong, and it may be disk size related instead. |
@roadrunner2 mine is 14,1, which has the Apple controller. Edit: Speaking of disk size, you reminded me of something quite weird. This is the first laptop with NVMe I have, so I don't know how it's supposed to work, but is it normal to have
What's that 8K |
@peterychuang Interesting: it looks like you have a second nvme namespace - no idea what that's doing there, though - I don't see that on my system. Not sure if anything in |
@roadrunner2 |
I just want to point out that when it drops to emergency shell after timing out, I can still boot into the machine by mounting the root partition to
I haven't tried this enough times to say this works 100% of the time though. |
@roadrunner2: About that second nvme namespace: Linux 4.13 has support for the Alpine Ridge Thunderbolt controller built into 2016+ MacBook Pros and exposes the EEPROM on each controller as an nvmem device. And @peterychuang mentions above that he's playing with linux-next, so he's already got all the 4.13 material and then some. I suspect that's where the second nvme namespace is coming from. If this theory is correct there should be a third one on models with two Thunderbolt controllers. |
@l1k: I just had a look on my MacBookPro13,2 which has two Thunderbolt controllers, but I only got the same second namespace as @peterychuang and no third one with Linux 4.13.0-rc1. |
@l1k I've just gone back to the stock kernel of Arch, which is 4.12.4 at the moment. The second namespace is present there too. |
I still see this issue with 4.15.2 (self-compiled kernel and running Debian). |
I haven't seen the issue yet with tens of boots of 4.15.2-ARCH. With older arch kernels and my self-compiled 4.14 it happened almost every single boot. So something cerainly must have changed in the kernel. |
I haven't had any problem for about three days now since 4.15.1. I'm not sure what NVMe changes in the kernel could be responsible for this either. If it wasn't the kernel, I am guessing perhaps firmware update might have helped? Have you upgraded to High Sierra 10.13.3? |
I haven't upgraded to High Sierra, and I can still reproduce the problem by booting older kernels. |
I might be good to compare kernel configs too (preferably same major version, e.g. 4.15). |
This is what the config looks like on the latest Arch Linux's stock kernel:
|
So, while I still had that problem with Linux 4.15 since upgrading to 4.16rc1 and installing macOS 10.13.3 I haven't seen this issue again, so I tend to believe it's now gone for good. Would be good though to know what caused it to disappear. |
I just had my first problem at boot since more than a month ago, so perhaps you are right that it hasn't been completely solved in 4.15.y. I don't really have time to mess with the mainline or next kernel these days, so I'll wait until 4.16 is officially out to see how that goes. |
After another two months without a single time this problem appeared again for me, I'm closing this issue now. If somebody encounters this problem again, please check if the latest macOS updates are installed. If yes, feel free to reopen this issue. |
Hello! I'm experiencing what I think is this problem again on distros running Linux kernels 4.18 and newer. I would be grateful for any support/suggestions that anyone has.
Let me know if there's any other information that's needed. |
@Ninja73737 Your issue seems to be a new different one than the one discussed in here, so please open a separate Github issue for it. |
someone posted a bugreport for the macbook8,1 (2015 12-inch), running kernel 5.2
|
@leifliddy Thanks for letting me know, I'll keep an eye on that! |
I wonder if that patch is actually causing the issue. Four years is a long time for a temporary patch. Perhaps the underlying issue has already been fixed. nvme is normally compiled as a module right?
Can't we just remove that patch and rebuild the nvme module and see if that works. BTW, I have a macbook9,1 with a slightly updated nvme controller :2003 vs :2001 (which is not affected by that patch)
#dmesg
|
Hi. I am the one reporting that issue on the kernel bugtracker. CONFIG_NVME_TARGET_FCLOOP is not setCONFIG_NVME_TARGET_TCP=m end of NVME Support |
AqauMCU sent me his dmesg log
looks like this is an IRQ assignment issue... which is detailed here: the possible solutions listed (macbook 8,1) are to:
|
Guys, please. You're currently discussing a separate topic than this issue is about, so please also open a separate one. |
That's exactly what I was trying to do by highlighting the fact that there's another thread discussing the exact issue that both Ninja73737 and AqauMCU are experiencing. |
i know here is not the place but wanted to help edit kernel/drivers/nvme/host/pci.c and modify tested with kernel 5.4.5 and works so far |
Are you going to submit this upstream? |
no idea yet, |
@npx001 I'm just curious. What macbook model do you have? |
Here we are: File: mac-nvme-0x2001-disk-image.bin Simple |
People reported that old Apple machines are not working properly if the non-first IRQ vector is in use. Set quirk for that models to limit IRQ to use first vector only. Based on original patch by GitHub user npx001. Link: Dunedan/mbp-2016-linux#9 Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Leif Liddy <leif.liddy@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Keith Busch <kbusch@kernel.org>
[ Upstream commit 98f7b86 ] People reported that old Apple machines are not working properly if the non-first IRQ vector is in use. Set quirk for that models to limit IRQ to use first vector only. Based on original patch by GitHub user npx001. Link: Dunedan/mbp-2016-linux#9 Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Leif Liddy <leif.liddy@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 98f7b86 ] People reported that old Apple machines are not working properly if the non-first IRQ vector is in use. Set quirk for that models to limit IRQ to use first vector only. Based on original patch by GitHub user npx001. Link: Dunedan/mbp-2016-linux#9 Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Leif Liddy <leif.liddy@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
BugLink: https://bugs.launchpad.net/bugs/1867178 [ Upstream commit 98f7b86 ] People reported that old Apple machines are not working properly if the non-first IRQ vector is in use. Set quirk for that models to limit IRQ to use first vector only. Based on original patch by GitHub user npx001. Link: Dunedan/mbp-2016-linux#9 Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Leif Liddy <leif.liddy@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com>
Hi, sorry if this is the very wrong place and time, but I have encountered an issue when installing POP!_OS 20.10 (dual-booting along a macOS APFS partition) on my MacBookPro13,1 to which this thread seems relevant. The installer.log reads
Could someone help me and tell me if this thread is right place to look for answers or point me in another direction? Thank you very much. |
I am trying to install Ubuntu on a MBP 13,1. From try ubuntu I can do the NVMe workaround and detect the flash drive. After I install ubuntu on the drive and try to boot up, it gets a dark red screen, I believe it get stuck at the grub and grub cannot recognise the flash drive. My question is how can we do the workaround at this stage? Or what is the correct way to get Ubuntu install?
The text was updated successfully, but these errors were encountered: