5.5.3. Núcleo
El módulo i40iw no se carga automáticamente en el arranque
Debido a que muchos NICs i40e no soportan iWarp y el módulo i40iw no soporta completamente la suspensión/reanudación, este módulo no se carga automáticamente por defecto para asegurar que la suspensión/reanudación funcione correctamente. Para solucionar este problema, edite manualmente el archivo /lib/udev/rules.d/90-rdma-hw-modules.rules
para activar la carga automática de i40iw.
Tenga en cuenta también que si hay otro dispositivo RDMA instalado con un dispositivo i40e en la misma máquina, el dispositivo RDMA no i40e activa el servicio rdma, que carga todos los módulos de pila RDMA habilitados, incluido el módulo i40iw.
(BZ#1623712)
El sistema a veces no responde cuando se conectan muchos dispositivos
Cuando Red Hat Enterprise Linux 8 configura un gran número de dispositivos, se produce un gran número de mensajes de consola en la consola del sistema. Esto sucede, por ejemplo, cuando hay un gran número de números de unidades lógicas (LUNs), con múltiples rutas a cada LUN. La avalancha de mensajes de consola, además de otros trabajos que está realizando el kernel, puede hacer que el watchdog del kernel fuerce un pánico del kernel porque éste parece estar colgado.
Debido a que el escaneo ocurre al principio del ciclo de arranque, el sistema deja de responder cuando hay muchos dispositivos conectados. Esto suele ocurrir en el momento del arranque.
Si kdump
está habilitado en su máquina durante el evento de escaneo de dispositivos después del arranque, el bloqueo duro resulta en una captura de una imagen vmcore
.
Para solucionar este problema, aumente el temporizador de bloqueo de watchdog. Para ello, añada la opción watchdog_thresh=N
a la línea de comandos del kernel. Sustituya N
por el número de segundos:
-
Si tiene menos de mil dispositivos, utilice
30
. -
Si tienes más de mil dispositivos, utiliza
60
.
Para el almacenamiento, el número de dispositivo es el número de rutas a todos los LUNs: generalmente, el número de dispositivos /dev/sd*
.
Después de aplicar la solución, el sistema ya no deja de responder cuando se configura una gran cantidad de dispositivos.
(BZ#1598448)
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 controlador qede
cuelga el NIC y lo hace inutilizable
Debido a un error, el controlador qede
para las NIC de la serie 41000 y 45000 de QLogic puede hacer que las operaciones de actualización de firmware y de recopilación de datos de depuración fallen y que la NIC quede inutilizada o en estado colgado hasta que el reinicio (PCI reset) del host haga que la NIC vuelva a estar operativa.
Este problema se ha detectado en todos los escenarios siguientes:
- cuando se actualiza el firmware del NIC utilizando el controlador de la bandeja de entrada
-
al recoger datos de depuración ejecutando el comando
ethtool -d ethx
-
ejecutando el comando
sosreport
ya que incluyeethtool -d ethx.
- cuando el controlador de la bandeja de entrada inicia la recopilación automática de datos de depuración, como el tiempo de espera de IO, el tiempo de espera de los comandos del buzón y una atención de hardware.
En el futuro, Red Hat publicará una fe de erratas a través de Red Hat Bug Advisory (RHBA) para solucionar este problema. Para solucionar este problema, cree un caso en https://access.redhat.com/support para solicitar una solución compatible con el problema hasta que se publique el RHBA.
(BZ#1697310)
Se han añadido símbolos de árboles radicales a kernel-abi-whitelists
Se han añadido los siguientes símbolos del árbol radial al paquete kernel-abi-whitelists
en Red Hat Enterprise Linux 8:
-
__radix_tree_insert
-
__radix_tree_next_slot
-
radix_tree_delete
-
radix_tree_gang_lookup
-
radix_tree_gang_lookup_tag
-
radix_tree_next_chunk
-
radix_tree_preload
-
radix_tree_tag_set
Los símbolos anteriores no deberían estar presentes y serán eliminados de la lista blanca de RHEL8.
(BZ#1695142)
podman
falla al comprobar un contenedor en RHEL 8
La versión del paquete Checkpoint and Restore In Userspace (CRIU) es obsoleta en Red Hat Enterprise Linux 8. Como consecuencia, CRIU no soporta la funcionalidad de checkpoint y restauración de contenedores y la utilidad podman
falla al realizar el checkpoint de contenedores. Cuando se ejecuta el comando podman container checkpoint
, se muestra el siguiente mensaje de error 'checkpointing a container requires at least CRIU 31100'
(BZ#1689746)
early-kdump
y kdump
estándar fallan si se utiliza la opción add_dracutmodules =earlykdump
en dracut.conf
Actualmente, se produce una incoherencia entre la versión del núcleo que se instala para early-kdump
y la versión del núcleo para la que se genera initramfs
. Como consecuencia, al arrancar con early-kdump
activado, early-kdump
falla. Además, si early-kdump
detecta que está siendo incluido en una imagen kdump
initramfs estándar, fuerza una salida. Por lo tanto, el servicio estándar de kdump
también falla al intentar reconstruir kdump
initramfs si early-kdump
se añade como módulo predeterminado de dracut
. Como consecuencia, tanto early-kdump
como kdump
estándar fallan. Para solucionar este problema, no agregue add_dracutmodules =earlykdump
o cualquier configuración equivalente en el archivo dracut.conf
. Como resultado, early-kdump
no es incluido por dracut
por defecto, lo que evita que el problema ocurra. Sin embargo, si se requiere una imagen de early-kdump
, tiene que ser creada manualmente.
(BZ#1662911)
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)
La interfaz de red pasa a llamarse kdump-<nombre-de-interfaz>
cuando se utiliza fadump
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, la interfaz de red se renombra como kdump-<nombre-de-interfaz>
si <nombre-de-interfaz>
es genérico, por ejemplo, *eth#, o net#. Este problema se produce 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 nomenclatura persistente. El mismo initrd
se utiliza también para un arranque normal, por lo que el nombre de la interfaz se cambia también para el kernel de producción.
(BZ#1745507)