Para ver se você pode fazer o BIOS reconhecer seu M.2. drive, você poderia tentar:
(nota: não posso postar mais de 8 links atualmente, mas você pode ver todas as capturas de tela sobre este comentário essencial: link )
* na página em Advanced\Onboard Devices Configuration , você pode mexer nas configurações: Hyper M.2X16 , M.2_1 Configuration , M.2_2 PCIe Bandwidth Configuration: [X2][X4] .
* Tente mexer com a configuração PCIe Speed na página Advanced\PCH Configuration\PCI Express Configuration .
* Tente desativar (ou ativar? Nah, provavelmente não ativando!) Aggressive LPM Support da página Advanced\PCH Storage Configuration .
* tente atualizar sua BIOS (screenshots dizem que é a versão 0616, a mais nova é 1002 ) - tenha cuidado embora, após a atualização, todas as suas configurações de BIOS (mesmo aquelas salvas nos perfis, mas não aquelas salvas como arquivos em algumas unidades USB, obviamente) sejam perdidas e permaneçam nos padrões do BIOS.
Outras coisas que você pode tentar, temporariamente :
* Certifique-se de que ErP Ready seja Disabled . Quando isso é Enabled , ele define / ativa outras configurações (em Advanced\Platform Misc Configuration page (veja a próxima tela), pelo menos) o que para mim fez com que meu teclado / mouse USB não fosse reconhecido no Linux (ou memtest86; por exemplo. OS inicializados) devido a algo ter entrado no modo de baixa potência (ou algo similar), na verdade, apenas a BIOS os veria.
* Garantir tudo em esta página ( Advanced\Platform Misc Configuration ) são desativado, só para ter certeza que seu M.2. drive de alguma forma não entrou em algum estado que é efetivamente colocado para dormir (embora isso nunca deve acontecer enquanto dentro da BIOS / GUI).
* Você pode definir POST Report para Until Press ESC (está em Avançado em Boot\Boot Configuration ) para que você possa ver o que a tela do POST diz ter detectado, normalmente diria algo sobre as unidades.
* A configuração Fast Boot provavelmente não tem efeito sobre isso, apenas pensei em mencioná-la de qualquer maneira.
* Talvez você possa verificar a tela em Advanced\PCH Storage Configuration , onde os dispositivos SATA podem ser Disabled , apenas para ver se há M.2. dispositivos que podem / são Disabled .
* verifique Advanced\HDD/SSD SMART Information para ver se você pode selecionar sua unidade M.2 na lista Device . Isso ajuda a ver se o BIOS pode vê-lo.
* Talvez você possa mexer com a configuração DMI Max Link Speed que está na página Advanced\System Agent (SA) Configuration\DMI/OPI Configuration . Eu atualmente não sei o que é essa configuração e se isso deve afetar qualquer coisa relacionada ao M.2.
* você já tentou desabilitar o CSM (Compatibility Support Module) e não ajudou (de acordo com os comentários sobre sua pergunta)
O seguinte pode ser aplicado, mas, acredito que primeiro ele deve ser reconhecido no BIOS: (embora possa ser possível que o Linux ainda o detecte mesmo que o BIOS não o detecte, ou talvez apenas se o BIOS tiver desativado, não tenho certeza)
Há um kernel do Linux commit ( 467c77d4cbefaaf65e2f44fe102d543a52fcae5b ) autor e comprometido em 11 de março de 2018, que diz:
nvme-pci: disable APST for Samsung NVMe SSD 960 EVO + ASUS PRIME Z370-A
Yet another "incompatible" Samsung NVMe SSD 960 EVO and Asus motherboard combination. 960 EVO device disappears from PCIe bus within few minutes after boot-up when APST is in use and never gets back. Forcing NVME_QUIRK_NO_APST is the only way to make this drive work with this particular motherboard. NVME_QUIRK_NO_DEEPEST_PS doesn't work, upgrading motherboard's BIOS didn't help either. Since this is a desktop motherboard, the only drawback of not using APST is increased device temperature.
Por isso, acredito que o mesmo acontece com sua unidade: Samsung SSD 970 EVO NVMe M.2 250GB .
Se você sentir vontade de recompilar o kernel do Linux:
Você poderia tentar iniciar qualquer uma das seguintes versões de kernels (que devem conter este commit):
v4.19-rc2 v4.19-rc1 v4.18 v4.18-rc8 v4.18-rc7 v4.18-rc6 v4.18-rc5 v4.18-rc4 v4.18-rc3 v4.18-rc2 v4. 18-rc1 v4.17 v4.17-rc7 v4.17-rc6 v4.17-rc5 v4.17-rc4 v4.17-rc3 v4.17-rc2 v4.17-rc1 E provavelmente qualquer versão não-rc também, so: 4.17, 4.18 e o ainda não lançado 4.19 (então apenas -rc2 e -rc1 estão disponíveis a partir deste).
Em seguida, veja se lspci -nn mostra seu dispositivo M.2 pelo nome seguido por dois números hexadecimais [vendor:device] (deve começar com [144d:XXXX] ) e verifique se esses números no final da linha são um valor diferente de [144d:a804] ( é o 960 EVO SSD que eles mencionam no commit), isso provavelmente significa que o commit / patch acima não estará em vigor para o seu drive, mas se você puder recompilar o kernel você pode adicionar os números [vendor:device] do seu dispositivo ao if bloco, em seguida, veja se a unidade funciona; se isso acontecer, talvez também denuncie para o bugzilla do kernel , para que eles também possam adicioná-lo ao bloco if .