11.6. Kernel

A remoção acidental do patch faz com que o enorme_page_setup_helper.py mostre erro

Um adesivo que atualiza o enorme_página_setup_helper.py script, foi removido acidentalmente. Consequentemente, após a execução do script huge_page_setup_helper.py, aparece a seguinte mensagem de erro:

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.

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.

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.

zlib pode retardar uma captura de vmcore em algumas funções de compressão

O arquivo de configuração kdump usa o formato de compressão lzo(makedumpfile -l) por padrão. Ao modificar o arquivo de configuração usando o formato de compressão zlib(makedumpfile -c), é provável que ele traga um fator de compressão melhor às custas de retardar o processo de captura do vmcore. Como conseqüência, o kdump leva até quatro vezes mais tempo para capturar um vmcore com zlib, em comparação com o lzo.

Uma captura vmcore falha após a operação de hot-plug de memória ou de desconectar a tomada

Após realizar a operação hot-plug ou hot-unplug de memória, o evento vem após a atualização da árvore do dispositivo que contém informações sobre o layout da memória. Assim, o utilitário makedump tenta acessar um endereço físico inexistente. O problema aparece se todas as seguintes condições forem atendidas:

O mecanismo fadump dumping renomeia a interface da rede para kdump-<interface-name>

Ao utilizar o lixão assistido por firmwares (fadump) para capturar um vmcore e armazená-lo em uma máquina remota usando o protocolo SSH ou NFS, renomeia a interface de rede para kdump-<interface-name>. A renomeação acontece quando o <interface-name> é genérico, por exemplo, *eth#, ou net# e assim por diante. Este problema ocorre porque os scripts de captura do vmcore no disco RAM inicial (initrd) adicionam o prefixo kdump- ao nome da interface de rede para garantir a nomeação persistente. Como o mesmo initrd também é usado para uma inicialização regular, o nome da interface é alterado também para o kernel de produção.

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.

O uso do irqpoll causa falha na geração de vmcore

Devido a um problema existente com o driver nvme nas arquiteturas ARM de 64 bits que rodam nas plataformas de nuvem Amazon Web Services (AWS), a geração vmcore falha quando você fornece o parâmetro de linha de comando do kernel irqpoll para o primeiro kernel. Conseqüentemente, nenhum arquivo vmcore é despejado no diretório /var/crash/ após uma falha do kernel. Para contornar este problema:

O uso da memória vPMEM como alvo de despejo atrasa o processo de captura de falhas do kernel

Quando você usa a Memória Virtual Persistente (vPEM) como alvo kdump ou fadump, o módulo papr_scm é forçado a desenhar e refazer a memória com o respaldo do vPMEM e readicionar a memória em seu mapa linear. Conseqüentemente, este comportamento aciona as chamadas Hypervisor (HCalls) para o Hypervisor POWER, e o tempo total gasto, retarda consideravelmente a inicialização do kernel de captura. Portanto, recomenda-se não usar os espaços de nomes vPMEM como alvo de despejo para kdump ou fadump.

O cão de guarda HP NMI nem sempre gera um depósito de lixo

Em certos casos, o motorista hpwdt para o cão de guarda HP NMI não é capaz de reivindicar uma interrupção não-máscara (NMI) gerada pelo temporizador HPE porque o NMI foi consumido pelo motorista perfmon.

O comando powersave de perfil afinado faz com que o sistema não responda

A execução do comando powersave de perfil tuned-adm leva a um estado não responsivo dos sistemas de 2-socket Penguin Valkyrie 2000 com os processadores Thunderx (CN88xx) mais antigos. Consequentemente, reinicialize o sistema para retomar o funcionamento. Para contornar este problema, evite usar o perfil powersave se seu sistema estiver de acordo com as especificações mencionadas.

O driver cxgb4 causa uma falha no kdump kernel

O kdump kernel quebra ao tentar salvar informações no arquivo vmcore. Conseqüentemente, o driver cxgb4 impede que o kdump kernel salve um núcleo para análise posterior. Para contornar este problema, adicione o parâmetro novmcoredd à linha de comando do kdump kernel para permitir salvar arquivos do núcleo.

A tentativa de adicionar a porta NIC do driver ICE a um modo 5(balance-tlb) de ligação da interface mestre pode levar a falhas

Tentar adicionar a porta NIC do driver ICE a uma interface mestre de ligação modo 5 (balance-tlb) pode levar a uma falha com um erro Master 'bond0', Slave 'ens1f0': Erro: Ens1f0": Erro: Falha no escravo. Conseqüentemente, você experimenta uma falha intermitente ao adicionar a porta NIC à interface mestre de colagem. Para solucionar este problema, tente tentar novamente adicionar a interface.

Anexar a Função Virtual à máquina virtual com interface tipo='hostdev' pode falhar em alguns momentos

Anexar uma função virtual (VF) a uma máquina virtual usando um arquivo .XML, seguindo o método Assignment with <interface type='hostdev'>, pode falhar em alguns momentos. Isto ocorre porque a utilização do método Assignment with <interface type='hostdev'> impede a VM de anexar a VF NIC apresentada a esta máquina virtual. Para resolver este problema, anexe a VF à VM usando o arquivo .XML, usando o método Assignment with <hostdev>. Como resultado, o comando virsh attach-device é bem sucedido sem erros. Para mais detalhes sobre a diferença entre Assignment with <hostdev> e Assignment with <interface type='hostdev'> (somente dispositivos SRIOV), veja PCI Passthrough de dispositivos de rede host.