6.7.8. Kernel
O módulo i40iw não é carregado automaticamente na inicialização
Devido a muitos DNIs i40e não suportarem iWarp e o módulo i40iw não suportar totalmente suspensão/resumo, este módulo não é carregado automaticamente por padrão para garantir que a suspensão/resumo funcione corretamente. Para resolver este problema, edite manualmente o arquivo /lib/udev/rules.d/90-rdma-hw-modules.rules para permitir o carregamento automático de i40iw.
Observe também que se houver outro dispositivo RDMA instalado com um dispositivo i40e na mesma máquina, o dispositivo não i40e RDMA aciona o serviço rdma, que carrega todos os módulos de pilha RDMA habilitados, incluindo o módulo i40iw.
(BZ#1623712)
A interface de rede é renomeada para kdump -<interface-nomee> quando o fadump é usado
Quando o dump assistido por firmwares(fadump) é utilizado para capturar um vmcore e armazená-lo em uma máquina remota usando o protocolo SSH ou NFS, a interface de rede é renomeada para kdump -<interface-nome_TERNGREGUNA- se <interface-nome_TERNGREGUNA- for genérica, por exemplo, *eth#, ou net#. Este problema ocorre porque os scripts de captura vmcore no disco inicial da RAM(initrd) adicionam o prefixo kdump- ao nome da interface de rede para garantir a nomeação persistente. O mesmo initrd é usado também para uma inicialização regular, de modo que o nome da interface é alterado também para o kernel de produção.
(BZ#1745507)
Sistemas com uma grande quantidade de experiências de memória persistente atrasam durante o processo de inicialização
Sistemas com uma grande quantidade de memória persistente levam muito tempo para arrancar porque a inicialização da memória é feita em série. Consequentemente, se houver sistemas de arquivo de memória persistente listados no arquivo /etc/fstab, o sistema pode demorar enquanto espera que os dispositivos fiquem disponíveis. Para contornar este problema, configure a opção DefaultTimeoutStartSec no arquivo /etc/systemd/system.conf para um valor suficientemente grande.
(BZ#1666538)
A KSM às vezes ignora as políticas de memória NUMA
Quando o recurso de memória compartilhada do kernel (KSM) é ativado com o parâmetro merge_across_nodes=1, o KSM ignora as políticas de memória definidas pela função mbind(), e pode fundir páginas de algumas áreas de memória com nós de Acesso Não-Uniforme à Memória (NUMA) que não correspondem às políticas.
Para contornar este problema, desative o KSM ou configure o parâmetro merge_across_nodes para 0 se estiver usando a ligação de memória NUMA com QEMU. Como resultado, as políticas de memória NUMA configuradas para a KVM VM funcionarão como esperado.
(BZ#1153521)
O sistema entra no modo de emergência no momento da inicialização quando o fadump é ativado
O sistema entra no modo de emergência quando fadump (kdump) ou dracut o módulo squash é ativado no esquema initramfs porque o gerente systemd não consegue pegar as informações de montagem e configurar a partição LV para montar. Para contornar este problema, adicione o seguinte parâmetro de linha de comando do kernel rd.lvm.lv=<VG>/<LV> para descobrir e montar a partição LV falhada de forma apropriada. Como resultado, o sistema inicializará com sucesso no cenário descrito.
(BZ#1750278)
O uso do irqpoll na linha de comando do kdump kernel causa uma falha na geração de vmcore
Devido a um problema subjacente existente com o driver nvme nas arquiteturas ARM de 64 bits rodando nas plataformas de nuvem da Amazon Web Services (AWS), a geração vmcore falha se o argumento da linha de comando irqpoll kdump for fornecido ao primeiro kernel. Conseqüentemente, nenhum vmcore é despejado no diretório /var/crash/ após uma falha do kernel. Para contornar este problema:
-
Adicionar
irqpollà chaveKDUMP_COMMANDLINE_REMOVEno arquivo /etc/sysconfig/kdump. -
Reinicie o serviço
kdumpexecutando o comandosystemctl restart kdump.
Como resultado, espera-se que o primeiro kernel seja capturado corretamente e que o vmcore seja capturado na quebra do kernel.
(BZ#1654962)
O núcleo de depuração não inicia no ambiente de captura de falhas no RHEL 8
Devido à natureza exigente de memória do núcleo de depuração, ocorre um problema quando o núcleo de depuração está em uso e um pânico do núcleo é desencadeado. Como conseqüência, o kernel debug não é capaz de inicializar como o kernel de captura, e em seu lugar é gerado um traço de pilha. Para contornar este problema, aumente a memória do kernel debug de acordo. Como resultado, o kernel debug arranca com sucesso no ambiente de captura de falhas.
(BZ#1659609)
as mudanças desoftirq podem fazer com que a interface do localhost deixe cair os pacotes UDP quando sob carga pesada
Mudanças no manuseio do software de interrupção(softirq) do kernel Linux são feitas para reduzir os efeitos da negação de serviço (DOS). Conseqüentemente, isto leva a situações em que a interface localhost deixa cair os pacotes do Protocolo de Datagramas do Usuário (UDP) sob carga pesada.
Para contornar este problema, aumente o tamanho do buffer de backlog do dispositivo de rede para o valor 6000:
echo 6000 > /proc/sys/net/core/netdev_max_backlog
Nos testes da Red Hat, este valor era suficiente para evitar a perda de pacotes. Sistemas mais carregados podem exigir valores de backlog maiores. O aumento do backlog tem o efeito de um potencial aumento da latência na interface localhost.
O resultado é aumentar o buffer e permitir que mais pacotes estejam esperando para serem processados, o que reduz as chances de queda de pacotes locais.
(BZ#1779337)
