Resolución a bloqueos producidos por hardware

2 envíos / 0 nuevos
Último envío
#1 Lun, 26/07/2021 - 07:44
Vicente Fab Gar
Imagen de Vicente Fab Gar
Desconectado/a
se unió: 13/11/17

Resolución a bloqueos producidos por hardware

Buenos dias,

Como continuación y resolución al tema que abrí en su día en este mismo foro:

https://exdebian.org/foro/algunos-errores-al-actualizar-kernel-510-solucionado

y como queda desvirtuado por ser la solución no apropiada ni pertenecer a un problema de actualización del kernel, paso a detallar cómo, después de horas, dias, semanas y meses... he podido acabar de una p. vez con esto.

Mi equipo ERAZER-X7745D monta una placa del fabricante MEDION con un NVME m.2 y un HDD. SO. Windows 10 de fábrica (Año 2017). Al instalar Debian, o incluso en Ubuntu y Fedora obtenía el mismo bloqueo de pantalla, teclado, ratón, unas veces a los pocos segundo de arrancar y otras en un espacio de horas aleatoriamente. Tras lograr contactar con el Soporte Técnico de MEDION un técnico me indicó que estos equipos estaban preparados para correr Windows, que no me podía dar soporte directo y que si quería solucionar el problema en linux que empezase a probar con el módulo ACPI, y así hice, a desactivar este módulo de energía, a deshabilitar los nucleos virtuales, etc. pero el problema siempre empezaba de nuevo.

Una de las instaciones, en Ubuntu y Kubuntu me puso alerta, pues en la instalación arrojaba un fallo en NVME m.2:

fsyncing/closing/.... input/output error

me dejaba instalar, pero al rato de vuelta con los bloqueos. Así se me ocurrio una instalación dual con W10+Ubuntu y estos bloqueos desaparecian por arte de magia. ¿Por qué? Es como si se me obligara a tener instalado Windows 10 para poder funcionar con GNU/Linux. Yo lo que quería era solo linux, ni si quiera cambiando las opciones UEFI - CSM - Secure boot  en la UEFI, tabla particiones MBR, GPT,  obtenia el resultado esperado. Esta placa base de MEDION es una auténtica vergüenza, por este y otros motivos, y de las mierdecillas de Microsoft no voy a hablar porque no es el lugar ni el momento.

Empecé un nuevo enfoque, el disco NVME y vi que algunos usuarios reportaban el mismo error y lo achaban a la memoria y no al ACPI. Finalmente, agregué

"nvme_core.default_ps_max_latency_us=0" a la linea de comandos de GRUB, quedando de la siguiente manera y probado en ambas distros:

En Debian: GRUB_CMDLINE_LINUX="quiet nvme_core.default_ps_max_latency_us=0"

En Ubuntu: GRUB_CMDLINE_LINUX="quiet splash nvme_core.default_ps_max_latency_us=0"

update-grub

y listo!! mi pc lleva varios dias sin ningún bloqueo o reinicio aleatorio.

 

Espero que le pueda servir a alguien.

Saludos.

 

Lun, 26/07/2021 - 13:35
caliban
Imagen de caliban
Conectado
moderador
se unió: 14/01/16

Gracias por compartir la solución, seguramente a alguien le podra servir en algún momento.