6.5.6. Kernel

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)

O kernel retorna falsos avisos positivos nos sistemas IBM Z

No RHEL 8, os sistemas IBM Z estão faltando uma entrada de lista branca para a zona de memória ZONE_DMA para permitir o acesso do usuário. Consequentemente, o kernel retorna avisos falsos positivos, tais como: 

...
Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLUB object 'dma-kmalloc-192' (offset 0, size 144)!
WARNING: CPU: 0 PID: 8519 at mm/usercopy.c:83 usercopy_warn+0xac/0xd8
...

Os avisos aparecem ao acessar certas informações do sistema através da interface sysfs. Por exemplo, ao executar o script de debuginfo.sh.

Para contornar este problema, adicione o parâmetro hardened_usercopy=off à linha de comando do kernel.

Como resultado, nenhuma mensagem de advertência é exibida no cenário descrito.

(BZ#1660290)

A espera ocupada do serviço rngd causa o consumo total da CPU no modo FIPS

Uma nova fonte de entropia do kernel para o modo FIPS foi adicionada para kernels a partir da versão 4.18.0-193.10. Conseqüentemente, quando em modo FIPS, o serviço rngd ocupado espera na chamada do sistema de pesquisa() para o dispositivo /dev/random, causando assim um consumo de 100% do tempo da CPU. Para contornar este problema, pare e desabilite o rngd executando: 

# systemctl stop rngd
# systemctl disable rngd

Como resultado, a rngd não está mais ocupada aguardando a votação() no cenário descrito.

(BZ#1884857)

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:

  • Uma variante um poucoendiana do IBM Power System executa o RHEL 8.
  • O serviço kdump ou fadump está habilitado no sistema.

Consequentemente, o kernel de captura não consegue salvar o vmcore se uma falha no kernel for acionada após a operação hot-plug ou hot-unplug da memória.

Para contornar este problema, reinicie o serviço kdump após o hot-plug ou hot-unplug: 

# systemctl restart kdump.service

Como resultado, o vmcore é salvo com sucesso no cenário descrito.

(BZ#1793389)

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:

  1. Adicionar irqpoll à chave KDUMP_COMMANDLINE_REMOVE no arquivo /etc/sysconfig/kdump.
  2. Reinicie o serviço kdump executando o comando systemctl restart kdump.

Como resultado, espera-se que o primeiro kernel boots corretamente e o arquivo vmcore sejam capturados na falha do kernel.

Note que o serviço kdump pode usar uma quantidade significativa de memória do kernel para despejar o arquivo vmcore. Certifique-se de que o kernel de captura tenha memória suficiente disponível para o serviço de kdump.

(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)

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.

Como resultado, a Red Hat recomenda o uso do lzo padrão para os casos em que a velocidade é o principal fator de condução. Entretanto, se a máquina alvo estiver com pouco espaço disponível, a zlib é uma opção melhor.

(BZ#1790635)

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 NMI em falta é iniciado por uma de duas condições:

  1. O botão Generate NMI no software de gerenciamento do servidor Lights-Out (iLO) integrado. Este botão é acionado por um usuário.
  2. O cão de guarda hpwdt. A expiração por padrão envia um NMI para o servidor.

Ambas as seqüências tipicamente ocorrem quando o sistema não responde. Em circunstâncias normais, o manipulador do NMI para estas duas situações chama a função kernel panic( ) e se configurado, o serviço kdump gera um arquivo vmcore.

Devido à falta de MNI, no entanto, o pânico no núcleo( ) não é chamado e o vmcore não é coletado.

No primeiro caso (1.), se o sistema não reagiu, ele permanece assim. Para contornar este cenário, use o botão virtual Power para reinicializar ou ligar o servidor.

No segundo caso (2.), o NMI em falta é seguido 9 segundos depois por um reset do ASR (Automated System Recovery).

A linha de servidores HPE Gen9 experimenta este problema em porcentagens de um dígito. O Gen10 em uma freqüência ainda menor.

(BZ#1602962)

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.

(BZ#1609288)

O valor de impressão padrão 7 4 1 7 às vezes causa a falta de resposta temporária do sistema

O valor padrão 7 4 1 7 printk permite uma melhor depuração da atividade do kernel. Entretanto, quando acoplado a um console serial, esta configuração de impressão pode causar explosões intensas de E/S que podem fazer com que um sistema RHEL se torne temporariamente não responsivo. Para contornar este problema, adicionamos um novo perfil TuneD do console serial de otimização, que reduz o valor padrão da impressão para 4 4 1 7. Os usuários podem instrumentar seu sistema da seguinte forma: 

# perfil tuned-adm profile throughput performance optimize-console de série

Ter um valor de impressão mais baixo persistente durante uma reinicialização reduz a probabilidade de que o sistema fique pendurado.

Observe que esta mudança de configuração vem às custas da perda de informações extras de depuração.

Para mais informações sobre o recurso recém-adicionado, veja Um novo perfil TuneD de otimização-console serial para reduzir E/S para consoles seriais, baixando o valor da impressão .

(JIRA:RHELPLAN-28940)

O driver do kernel ACPI informa que não tem acesso a uma região de memória PCIe ECAM

A tabela Configuração Avançada e Interface de Alimentação (ACPI) fornecida pelo firmware não define uma região de memória no barramento PCI no método Current Resource Settings (_CRS) para o dispositivo de barramento PCI. Conseqüentemente, a seguinte mensagem de aviso ocorre durante a inicialização do sistema: 

[    2.817152] acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0x30000000-0x31ffffff] not reserved in ACPI namespace
[    2.827911] acpi PNP0A08:00: ECAM at [mem 0x30000000-0x31ffffff] for [bus 00-1f]

Entretanto, o kernel ainda é capaz de acessar a região de memória 0x30000000-0x31ffff, e pode atribuir essa região de memória ao Mecanismo de Acesso à Configuração Melhorada do PCI (ECAM) adequadamente. Você pode verificar se o PCI ECAM funciona corretamente ao acessar o espaço de configuração do PCIe sobre o offset de 256 bytes com a seguinte saída: 

03:00.0 Non-Volatile memory controller: Sandisk Corp WD Black 2018/PC SN720 NVMe SSD (prog-if 02 [NVM Express])
 ...
        Capabilities: [900 v1] L1 PM Substates
                L1SubCap: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+
                          PortCommonModeRestoreTime=255us PortTPowerOnTime=10us
                L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1-
                           T_CommonMode=0us LTR1.2_Threshold=0ns
                L1SubCtl2: T_PwrOn=10us

Como resultado, você pode ignorar a mensagem de aviso.

Para mais informações sobre o problema, veja o "Firmware Bug: ECAM area mem 0x30000000-0x31ffffff not reserved in ACPI namespace" aparece durante a solução de inicialização do sistema.

(BZ#1868526)

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.

(BZ#1708456)

A biblioteca MPI ABERTA pode desencadear falhas no tempo de execução com PML padrão

Na implementação da série 4.0.x da OPEN Message Passing Interface (OPEN MPI), a Comunicação Unificada X (UCX) é o comunicador ponto a ponto (PML) padrão. As versões posteriores da série OPEN MPI 4.0.x depreciaram a camada de transferência de bytes openib (BTL).

No entanto, OPEN MPI, quando executada sobre um cluster homogeneous (mesma configuração de hardware e software), a UCX ainda usa o openib BTL para operações unilaterais de MPI. Como conseqüência, isto pode desencadear erros de execução. Para contornar este problema:

  • Execute o comando mpirun usando os seguintes parâmetros: 
-mca btl openib -mca pml ucx -x UCX_NET_DEVICES=mlx5_ib0

onde,

  • O parâmetro -mca btl openib desactiva o openib BT L
  • O parâmetro -mca pml ucx configura o MPI ABERTO para usar o ucx PML.
  • O parâmetro x UCX_NET_DEVICES= restringe o UCX a usar os dispositivos especificados

O MPI ABERTO, quando executado sobre um cluster heterogeneous (configuração diferente de hardware e software), ele usa o UCX como o PML padrão. Como consequência, isto pode fazer com que os trabalhos MPI ABERTO funcionem com desempenho errático, comportamento não responsivo ou falhas de crash. Para contornar este problema, defina a prioridade do UCX como:

  • Execute o comando mpirun usando os seguintes parâmetros: 
-mca pml_ucx_priority 5

Como resultado, a biblioteca OPEN MPI é capaz de escolher uma camada alternativa de transporte disponível sobre a UCX.

(BZ#186666402)