5.5.3. 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)
O sistema às vezes fica sem resposta quando muitos dispositivos são conectados
Quando o Red Hat Enterprise Linux 8 configura um grande número de dispositivos, um grande número de mensagens do console ocorre no console do sistema. Isto acontece, por exemplo, quando há um grande número de unidades lógicas (LUNs), com múltiplos caminhos para cada LUN. O fluxo de mensagens do console, além de outros trabalhos que o kernel está fazendo, pode fazer com que o cão de guarda do kernel force o pânico do kernel porque o kernel parece estar pendurado.
Como a varredura acontece no início do ciclo de inicialização, o sistema torna-se insensível quando muitos dispositivos são conectados. Isto normalmente ocorre no momento da inicialização.
Se o kdump for ativado em sua máquina durante o evento de varredura do dispositivo após a inicialização, o bloqueio rígido resulta na captura de uma imagem vmcore.
Para contornar este problema, aumente o temporizador de bloqueio do cão de guarda. Para isso, adicione a opção watchdog_thresh=N à linha de comando do kernel. Substitua N com o número de segundos:
-
Se você tiver menos de mil dispositivos, use
30. -
Se você tiver mais de mil dispositivos, use
60.
Para armazenamento, o número de dispositivos é o número de caminhos para todos os LUNs: geralmente, o número de dispositivos /dev/sd*.
Após a aplicação da solução, o sistema não se torna mais insensível quando se configura uma grande quantidade de dispositivos.
(BZ#1598448)
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 motorista qede pendura o DNI e o torna inutilizável
Devido a um bug, o driver qede para as séries 41000 e 45000 QLogic NICs pode fazer com que as operações de atualização do Firmware e debug de coleta de dados falhem e tornar o NIC inutilizável ou em estado suspenso até que o reinício (PCI reset) do host torne o NIC operacional novamente.
Esta questão foi detectada em todos os cenários a seguir:
- ao atualizar o Firmware do NIC usando o driver da caixa de entrada
-
ao coletar dados de depuração rodando o comando
ethtool -d ethx -
rodando o comando
sosreport, pois incluiethtool -d ethx. - quando o motorista da caixa de entrada inicia a coleta automática de dados de depuração, tais como timeout IO, timeout de comando da caixa de correio e uma Atenção de Hardware.
Uma futura errata da Red Hat será lançada via Red Hat Bug Advisory (RHBA) para tratar desta questão. Para resolver este problema, crie um caso em https://access.redhat.com/support para solicitar uma correção suportada para o problema até que a RHBA seja lançada.
(BZ#1697310)
Símbolos de árvores Radix foram adicionados às listas de kernel-abi-whitelists
Os seguintes símbolos em árvore radix foram adicionados ao pacote kernel-abi-whitelists no 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
Os símbolos acima não deveriam estar presentes e serão removidos da lista branca RHEL8.
(BZ#1695142)
podman falha no ponto de verificação de um contêiner no RHEL 8
A versão do pacote Checkpoint and Restore In Userspace (CRIU) está desatualizada no Red Hat Enterprise Linux 8. Como conseqüência, o CRIU não suporta o Checkpoint and Restore In Userspace (CRIU) e o utilitário podman falha no Checkpoint Contêiner. Ao executar o comando podman de ponto de verificação de contêineres, a seguinte mensagem de erro é exibida: 'checkpointing a container requires at least CRIU 31100' (ponto de verificação de um contêiner requer pelo menos CRIU 31100)
(BZ#1689746)
early-kdump e kdump padrão falham se a opção add_dracutmodules =earlykdump for usada no dracut.conf
Atualmente, ocorre uma inconsistência entre a versão do kernel que está sendo instalada para o kdump inicial e a versão do kernel para a qual é gerado o initramfs. Como conseqüência, a inicialização com o early-kdump ativado, o early-kdump falha. Além disso, se o early-kdump detecta que está sendo incluído em uma imagem padrão do initramfs do kdump, ele força uma saída. Portanto, o serviço de kdump padrão também falha ao tentar reconstruir o kdump initramfs se o early-kdump for adicionado como um módulo de dracut padrão. Como conseqüência, tanto o early-kdump quanto o kdump padrão falham. Para contornar este problema, não adicione add_dracutmodules =earlykdump ou qualquer configuração equivalente no arquivo dracut.conf. Como resultado, o early-kdump não é incluído pelo dracut por padrão, o que impede que o problema ocorra. Entretanto, se uma imagem do early-kdump for necessária, ela tem que ser criada manualmente.
(BZ#1662911)
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)
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)
