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 incluye ethtool -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)

Red Hat logoGithubRedditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

© 2024 Red Hat, Inc.