11.6. Núcleo
La eliminación accidental del parche hace que huge_page_setup_helper.py muestre un error
Un parche que actualiza el script huge_page_setup_helper. py, fue eliminado accidentalmente. En consecuencia, tras ejecutar el script huge_page_setup_helper.py, aparece el siguiente mensaje de error:
SyntaxError: Faltan paréntesis en la llamada a 'print'
Para solucionar este problema, copie el script huge_page_setup_helper.py de RHEL 8.1 e instálelo en el directorio /usr/bin/:
-
Descargue el paquete
libhugetlbfs-utils-2.21-3.el8.x86_64.rpm desde el medio de instalación de RHEL-8.1.0 o desde el Portal del Cliente de Red Hat. Ejecute el comando
rpm2cpio:# rpm2cpio libhugetlbfs-utils-2.21-3.el8.x86_64.rpm | cpio -D / -iduv '*/huge_page_setup_helper.py'
El comando extrae el script
huge_page_setup_helper.pydel RPM de RHEL 8.1 y lo guarda en el directorio/usr/bin/.
Como resultado, el script huge_page_setup_helper.py funciona correctamente.
(BZ#1823398)
Los sistemas con una gran cantidad de memoria persistente experimentan retrasos durante el proceso de arranque
Los sistemas con una gran cantidad de memoria persistente tardan mucho en arrancar porque la inicialización de la memoria se hace en serie. Por lo tanto, si hay sistemas de archivos de memoria persistente listados en el archivo /etc/fstab, el sistema puede perder el tiempo mientras espera que los dispositivos estén disponibles. Para solucionar este problema, configure la opción DefaultTimeoutStartSec en el archivo /etc/systemd/system.conf con un valor suficientemente grande.
(BZ#1666538)
KSM a veces ignora las políticas de memoria NUMA
Cuando la función de memoria compartida del kernel (KSM) está activada con el parámetro merge_across_nodes=1, KSM ignora las políticas de memoria establecidas por la función mbind(), y puede fusionar páginas de algunas áreas de memoria a nodos de acceso a memoria no uniforme (NUMA) que no coinciden con las políticas.
Para solucionar este problema, desactive KSM o establezca el parámetro merge_across_nodes a 0 si utiliza la unión de memoria NUMA con QEMU. Como resultado, las políticas de memoria NUMA configuradas para la VM KVM funcionarán como se espera.
(BZ#1153521)
El kernel de depuración no arranca en el entorno de captura de fallos en RHEL 8
Debido a la naturaleza de demanda de memoria del kernel de depuración, se produce un problema cuando el kernel de depuración está en uso y se desencadena un pánico del kernel. Como consecuencia, el kernel de depuración no es capaz de arrancar como el kernel de captura, y en su lugar se genera una traza de pila. Para solucionar este problema, aumente la memoria del kernel de captura en consecuencia. Como resultado, el kernel de depuración arranca con éxito en el entorno de captura de fallos.
(BZ#1659609)
zlib puede ralentizar una captura de vmcore en algunas funciones de compresión
El archivo de configuración de kdump utiliza el formato de compresión lzo(makedumpfile -l) por defecto. Cuando se modifica el archivo de configuración utilizando el formato de compresión zlib, (makedumpfile-c) es probable que traiga un mejor factor de compresión a costa de ralentizar el proceso de captura de vmcore. Como consecuencia, el kdump tarda hasta cuatro veces más en capturar un vmcore con zlib, en comparación con lzo.
Como resultado, Red Hat recomienda utilizar el lzo por defecto para los casos en los que la velocidad es el factor principal. Sin embargo, si la máquina de destino tiene poco espacio disponible, zlib es una mejor opción.
(BZ#1790635)
Una captura de vmcore falla después de la operación de conexión o desconexión de la memoria
Después de realizar la operación de conexión o desconexión en caliente de la memoria, el evento se produce después de actualizar el árbol de dispositivos que contiene la información de la disposición de la memoria. De este modo, la utilidad makedumpfile intenta acceder a una dirección física inexistente. El problema aparece si se cumplen todas las condiciones siguientes:
- Una variante little-endian de IBM Power System ejecuta RHEL 8.
-
El servicio
kdumpofadumpestá activado en el sistema.
En consecuencia, el kernel de captura no guarda el vmcore si se produce un fallo del kernel después de la operación de conexión o desconexión en caliente de la memoria.
Para solucionar este problema, reinicie el servicio kdump después de conectar o desconectar en caliente:
# systemctl restart kdump.service
Como resultado, vmcore se guarda con éxito en el escenario descrito.
(BZ#1793389)
El mecanismo de volcado fadump cambia el nombre de la interfaz de red a kdump-<interface-name>
Cuando se utiliza el volcado asistido por firmware (fadump) para capturar un vmcore y almacenarlo en una máquina remota utilizando el protocolo SSH o NFS, se renombra la interfaz de red a kdump-<interface-name>. El renombramiento ocurre cuando el <interface-name> es genérico, por ejemplo, *eth#, o net# y así sucesivamente. Este problema ocurre porque los scripts de captura de vmcore en el disco RAM inicial (initrd) añaden el prefijo kdump- al nombre de la interfaz de red para asegurar la persistencia del nombre. Como el mismo initrd se utiliza también para un arranque normal, el nombre de la interfaz se cambia también para el kernel de producción.
(BZ#1745507)
El sistema entra en el modo de emergencia en el momento del arranque cuando fadump está activado
El sistema entra en el modo de emergencia cuando se habilita el módulo de squash fadump (kdump) o dracut en el esquema initramfs porque el gestor systemd no consigue obtener la información de montaje y configurar la partición LV para montarla. Para solucionar este problema, añada el siguiente parámetro de línea de comandos del kernel rd.lvm.lv=<VG>/<LV> para descubrir y montar la partición LV fallida adecuadamente. Como resultado, el sistema arrancará con éxito en el escenario descrito.
(BZ#1750278)
El uso de irqpoll provoca un fallo en la generación de vmcore
Debido a un problema existente con el controlador nvme en las arquitecturas ARM de 64 bits que se ejecutan en las plataformas en la nube de Amazon Web Services (AWS), la generación de vmcore falla cuando se proporciona el parámetro de línea de comandos del kernel irqpoll al primer kernel. En consecuencia, no se vuelca ningún archivo vmcore en el directorio /var/crash/ después de un fallo del kernel. Para solucionar este problema:
-
Añade
irqpolla la claveKDUMP_COMMANDLINE_REMOVEen el archivo/etc/sysconfig/kdump. -
Reinicie el servicio
kdumpejecutando el comandosystemctl restart kdump.
Como resultado, el primer kernel arranca correctamente y se espera que el archivo vmcore sea capturado al caer el kernel.
Tenga en cuenta que el servicio kdump puede utilizar una cantidad significativa de memoria del kernel de captura para volcar el archivo vmcore. Asegúrese de que el kernel de captura tiene suficiente memoria disponible para el servicio kdump.
(BZ#1654962)
El uso de la memoria vPMEM como objetivo de volcado retrasa el proceso de captura de fallos del kernel
Cuando se utilizan espacios de nombres de memoria persistente virtual (vPEM) como objetivo de kdump o fadump, el módulo papr_scm se ve obligado a desmapear y remapear la memoria respaldada por vPMEM y a volver a añadir la memoria a su mapa lineal. En consecuencia, este comportamiento desencadena llamadas del hipervisor (HCalls) al hipervisor POWER, y el tiempo total empleado, ralentiza considerablemente el arranque del kernel de captura. Por lo tanto, se recomienda no utilizar espacios de nombres vPMEM como objetivo de volcado para kdump o fadump.
Si debe utilizar vPMEM, para solucionar este problema ejecute los siguientes comandos:
Cree el archivo
/etc/dracut.conf.d/99-pmem-workaround.confy añada:add_drivers ="nd_pmem nd_btt libnvdimm papr_scm"
Reconstruir el sistema de archivos del disco RAM inicial (initrd):
# touch /etc/kdump.conf # systemctl restart kdump.service
(BZ#1792125)
El NMI watchdog de HP no siempre genera un volcado de fallos
En ciertos casos, el controlador hpwdt para el vigilante NMI de HP no puede reclamar una interrupción no enmascarable (NMI) generada por el temporizador del vigilante HPE porque el NMI fue consumido por el controlador perfmon.
La falta de NMI se inicia por una de dos condiciones:
- El botón Generate NMI en el software de gestión del servidor Integrated Lights-Out (iLO). Este botón es activado por un usuario.
-
El
hpwdtwatchdog. La expiración por defecto envía un NMI al servidor.
Ambas secuencias suelen ocurrir cuando el sistema no responde. En circunstancias normales, el manejador de NMI para ambas situaciones llama a la función kernel panic() y, si está configurado, el servicio kdump genera un archivo vmcore.
Sin embargo, debido a la falta de NMI, no se llama a kernel panic() y no se recoge vmcore.
En el primer caso (1.), si el sistema no responde, lo sigue haciendo. Para solucionar este escenario, utilice el botón virtual Power para reiniciar o apagar el servidor.
En el segundo caso (2.), el NMI que falta es seguido 9 segundos más tarde por un reinicio de la recuperación automática del sistema (ASR).
La línea de servidores HPE Gen9 experimenta este problema en porcentajes de un solo dígito. La Gen10 con una frecuencia aún menor.
(BZ#1602962)
El comando tuned-adm profile powersave hace que el sistema deje de responder
La ejecución del comando tuned-adm profile powersave conduce a un estado de falta de respuesta de los sistemas Penguin Valkyrie 2000 de 2 sockets con los procesadores Thunderx (CN88xx) más antiguos. En consecuencia, reinicie el sistema para que vuelva a funcionar. Para evitar este problema, evite utilizar el perfil powersave si su sistema cumple con las especificaciones mencionadas.
(BZ#1609288)
El controlador cxgb4 provoca un fallo en el kernel kdump
El kernel kdump se bloquea al intentar guardar información en el archivo vmcore. En consecuencia, el controlador cxgb4 impide que el kdump kernel guarde un núcleo para su posterior análisis. Para solucionar este problema, añada el parámetro novmcoredd a la línea de comandos de kdump kernel para permitir guardar archivos de núcleo.
(BZ#1708456)
El intento de añadir el puerto NIC del controlador ICE a una interfaz maestra de enlace en modo 5(balance-tlb) puede provocar un fallo
Al intentar añadir el puerto NIC del controlador ICE a una interfaz maestra de enlace en modo 5 (balance-tlb) puede producirse un fallo con un error Maestro 'bond0', Esclavo 'ens1f0': Error: Enslave failed. En consecuencia, se produce un fallo intermitente al añadir el puerto NIC a la interfaz maestra de enlace. Para solucionar este problema, intente volver a añadir la interfaz.
(BZ#1791664)
Adjuntar la función virtual a la máquina virtual con el tipo de interfaz='hostdev' puede fallar a veces
Adjuntar una Función Virtual (VF) a una máquina virtual utilizando un archivo .XML, siguiendo el método Assignment with <interface type='hostdev'>, puede fallar en ocasiones. Esto ocurre porque el uso del método Assignment with <interface type='hostdev'> impide que la VM se conecte a la NIC de la VF presentada a esta máquina virtual. Para solucionar este problema, adjunte el VF a la VM utilizando el archivo .XML con el método Assignment with <hostdev>. Como resultado, el comando virsh attach-device tiene éxito sin error. Para obtener más detalles sobre la diferencia entre Assignment with <hostdev> y Assignment with <interface type='hostdev'> (sólo dispositivos SRIOV), consulte PCI Passthrough de dispositivos de red de host.
(BZ#1792691)
