6.5.6. Núcleo
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)
El kernel devuelve falsos positivos en los sistemas IBM Z
En RHEL 8, los sistemas IBM Z carecen de una entrada en la lista blanca de la zona de memoria ZONE_DMA para permitir el acceso del usuario. En consecuencia, el kernel devuelve advertencias falsas positivas como:
... Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'dma-kmalloc-192' (offset 0, size 144)! WARNING: CPU: 0 PID: 8519 at mm/usercopy.c:83 usercopy_warn+0xac/0xd8 ...
Las advertencias aparecen cuando se accede a cierta información del sistema a través de la interfaz sysfs. Por ejemplo, al ejecutar el script debuginfo.sh.
Para solucionar este problema, añada el parámetro hardened_usercopy=off a la línea de comandos del kernel.
Como resultado, no se muestra ningún mensaje de advertencia en el escenario descrito.
(BZ#1660290)
La espera ocupada del servicio rngd provoca un consumo total de la CPU en modo FIPS
Se ha añadido una nueva fuente de entropía del kernel para el modo FIPS para los kernels que comienzan con la versión 4.18.0-193.10. En consecuencia, cuando está en modo FIPS, el servicio rngd está ocupado esperando la llamada al sistema poll() para el dispositivo /dev/random, lo que provoca un consumo del 100% del tiempo de la CPU. Para solucionar este problema, detenga y desactive rngd ejecutando
# systemctl stop rngd # systemctl disable rngd
Como resultado, rngd ya no ocupa las esperas de poll() en el escenario descrito.
(BZ#1884857)
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 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 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)
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 valor predeterminado de 7 4 1 7 printk a veces provoca una falta de respuesta temporal del sistema
El valor predeterminado 7 4 1 7 printk permite una mejor depuración de la actividad del kernel. Sin embargo, cuando se combina con una consola en serie, este valor printk puede causar intensas ráfagas de E/S que pueden hacer que un sistema RHEL deje de responder temporalmente. Para solucionar este problema, hemos añadido un nuevo perfil TuneD optimize-serial-console, que reduce el valor printk por defecto a 4 4 1 7. Los usuarios pueden instrumentar su sistema de la siguiente manera:
# tuned-adm profile throughput-performance optimize-serial-console
Tener un valor de printk más bajo persistente a través de un reinicio reduce la probabilidad de cuelgues del sistema.
Tenga en cuenta que este cambio de configuración se produce a costa de perder la información de depuración adicional.
Para más información sobre la nueva función, consulte Un nuevo perfil TuneD de optimización de consolas serie para reducir la E/S en las consolas serie reduciendo el valor de printk .
(JIRA:RHELPLAN-28940)
El controlador ACPI del kernel informa que no tiene acceso a una región de memoria PCIe ECAM
La tabla de la interfaz de configuración avanzada y alimentación (ACPI) proporcionada por el firmware no define una región de memoria en el bus PCI en el método de configuración de recursos actuales (_CRS) para el dispositivo de bus PCI. En consecuencia, se produce el siguiente mensaje de advertencia durante el arranque del sistema:
[ 2.817152] acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0x30000000-0x31ffffff] not reserved in ACPI namespace [ 2.827911] acpi PNP0A08:00: ECAM at [mem 0x30000000-0x31ffffff] for [bus 00-1f]
Sin embargo, el kernel sigue siendo capaz de acceder a la región de memoria 0x30000000-0x31ffff, y puede asignar esa región de memoria al Mecanismo de Acceso a la Configuración Mejorada (ECAM) de PCI correctamente. Puedes verificar que PCI ECAM funciona correctamente accediendo al espacio de configuración PCIe sobre el offset de 256 bytes con la siguiente salida:
03:00.0 Non-Volatile memory controller: Sandisk Corp WD Black 2018/PC SN720 NVMe SSD (prog-if 02 [NVM Express])
...
Capabilities: [900 v1] L1 PM Substates
L1SubCap: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+
PortCommonModeRestoreTime=255us PortTPowerOnTime=10us
L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
T_CommonMode=0us LTR1.2_Threshold=0ns
L1SubCtl2: T_PwrOn=10usPor lo tanto, puede ignorar el mensaje de advertencia.
Para más información sobre el problema, consulte la solución "Firmware Bug: ECAM area mem 0x30000000-0x31ffffff not reserved in ACPI namespace" que aparece durante el arranque del sistema.
(BZ#1868526)
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)
La biblioteca OPEN MPI puede provocar fallos en tiempo de ejecución con la PML por defecto
En la implementación de OPEN Message Passing Interface (OPEN MPI) de la serie 4.0.x, Unified Communication X (UCX) es el comunicador punto a punto (PML) por defecto. Las versiones posteriores de OPEN MPI de la serie 4.0.x obviaron openib Byte Transfer Layer (BTL).
Sin embargo, OPEN MPI, cuando se ejecuta sobre un cluster homogeneous (misma configuración de hardware y software), UCX sigue utilizando openib BTL para las operaciones MPI unilaterales. Como consecuencia, esto puede provocar errores de ejecución. Para solucionar este problema:
-
Ejecute el comando
mpiruncon los siguientes parámetros:
-mca btl openib -mca pml ucx -x UCX_NET_DEVICES=mlx5_ib0
donde,
-
El parámetro
-mca btl openibdesactivaopenibBTL -
El parámetro
-mca pml ucxconfigura OPEN MPI para utilizarucxPML. -
El parámetro
x UCX_NET_DEVICES=restringe a UCX el uso de los dispositivos especificados
El OPEN MPI, cuando se ejecuta sobre un cluster heterogeneous (diferente configuración de hardware y software), utiliza UCX como PML por defecto. Como consecuencia, esto puede provocar que los trabajos de OPEN MPI se ejecuten con un rendimiento errático, un comportamiento poco receptivo o fallos en la ejecución. Para solucionar este problema, configure la prioridad de UCX como
-
Ejecute el comando
mpiruncon los siguientes parámetros:
-mca pml_ucx_priority 5
Como resultado, la biblioteca OPEN MPI es capaz de elegir una capa de transporte alternativa disponible sobre UCX.
(BZ#1866402)
