Estoy montando un PC nuevo con una placa base ASUS PRIME Z370-A y un Samsung SSD 970 EVO NVMe M.2 250GB.
Sin embargo, mi placa base no parece ser capaz de reconocer la unidad, ya que ni aparece en UEFI ni en el instalador de Windows 10.
He probado a instalarla en los dos zócalos M.2 que tiene la placa base:
Sin embargo, la unidad no se reconoce en ninguno de los dos zócalos.
También he probado a aplicar varias configuraciones al módulo de soporte de compatibilidad y sigue sin detectarlo.
Fotos de la configuración UEFI:
¡¡ACTUALIZA!
Tuve que llevar mi pc a un técnico y, por lo que recuerdo hizo, poner otro ssd m.2 en la placa base, probó activando/desactivando opciones (la verdad no parecía que supiera lo que hace cada opción y era algo que yo también había probado) y en alguno de esos intentos, ¡eureka! el disco fue reconocido y apareció en el panel de configuración UEFI.
Quería saber cual de las opciones que activó era la indicada para que funcionara. Restauré las opciones al estado de fábrica y lo irónico fue que... ¡el disco seguía siendo reconocido por la tarjeta madre! Pudo ser que no encajé bien el disco en su zócalo, pero sinceramente hice varios intentos e incluso apliqué mucha fuerza que temí dañarlo.
Un misterio sin resolver. Pero lo importante es que funciona.
Para ver si puedes hacer que BIOS reconozca tu unidad M.2., podrías probar (nota: Puedes ver todas las capturas de pantalla en este comentario gist)
Advanced\Onboard Devices Configuration
, podrías jugar con los ajustes: Hyper M.2X16
, M.2_1 Configuration
, M.2_2 PCIe Bandwidth Configuration: [X2][X4]
. Velocidad PCIe
en la página Configuración avanzada de PCH
. Aggressive LPM Support
de la página Advanceded\PCH Storage Configuration
. ErP Ready
está Disabled
. Cuando esta Habilitado
, establece/habilita otras configuraciones (en la página Advanced\Platform Misc Configuration
(ver siguiente captura de pantalla), al menos) que en mi caso causó que mi teclado/ratón USB no fuera reconocido en Linux (o memtest86; por ejemplo, cualquier SO arrancado) debido a que algo había entrado en modo de bajo consumo (o algo similar), en efecto sólo BIOS los vería. Advanced\Platform Misc Configuration
) están deshabilitadas, sólo para asegurarse de que su unidad M.2. no ha entrado en un estado de suspensión (aunque esto nunca debería ocurrir mientras está dentro de la BIOS/GUI). POST Report
en Until Press ESC
(está en Advanced bajo Boot\Boot Configuration
) para que puedas ver lo que la pantalla POST dice que ha detectado, normalmente dirá algo sobre las unidades. Fast Boot
probablemente no tiene ningún efecto sobre esto, sólo pensé que lo mencionaría de todos modos. Advanced\PCH Storage Configuration
donde los dispositivos SATA pueden ser Disabled
, sólo para ver si hay M.2. dispositivos que pueden / son Disabled
. Advanced\HDD/SSD SMART Information
para ver si puede seleccionar su unidad M.2 de la lista Device
. Esto ayuda a ver si BIOS puede verlo. DMI Max Link Speed
ajuste que 's en la página Advanced\System Agent (SA) Configuration\DMI/OPI Configuration
. Actualmente no sé qué es ese ajuste y si se supone que afecta a algo relacionado con M.2.Lo siguiente podría aplicarse, pero, creo que primero tiene que ser reconocido en BIOS: (aunque puede ser posible que Linux aún lo detecte incluso si BIOS no lo detecta, o tal vez sólo si BIOS lo tiene deshabilitado, no estoy seguro) Hay un kernel Linux commit (kernel git) escrito y confirmado el 11 de marzo de 2018, que dice:
nvme-pci: deshabilitar APST para Samsung NVMe SSD 960 EVO + ASUS PRIME Z370-A > Otro "incompatible" Samsung NVMe SSD 960 EVO y placa base Asus combinación. Dispositivo 960 EVO desaparece del bus PCIe en pocos minutos después del arranque cuando APST está en uso y nunca vuelve. Forzando
NVME_QUIRK_NO_APST
es la única manera de hacer que esta unidad funcione con esta placa base en particular.NVME_QUIRK_NO_DEEPEST_PS
no funciona, actualizando la BIOS de la placa base tampoco ayudó. Dado que se trata de una placa base de sobremesa, el único inconveniente de no usar APST es el aumento de la temperatura del dispositivo. Así que supongo que ocurre lo mismo con tu unidad:Samsung SSD 970 EVO NVMe M.2 250GB
.
Si te apetece recompilar el kernel de Linux, podrías probar a arrancar cualquiera de las versiones del siguiente kernel (que debería contener este commit):
lspci -nn
muestra su dispositivo M.2 por su nombre seguido de dos números hexadecimales [vendor:device]
(debería empezar por [144d:XXXX]
), luego compruebe si esos números al final de la línea tienen un valor diferente de [144d:a804]
(ese es el SSD 960 EVO que mencionan en el commit). Probablemente significa que el commit/parche anterior no será efectivo para su unidad, pero si puede recompilar el kernel, podría añadir los números de su dispositivo [vendor:device]
a ese bloque if
, y ver si la unidad funciona; si lo hace, quizás también pueda informar de ello a kernel bugzilla para que puedan añadirlo también a ese bloque if
.