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
kdumpoufadumpestá 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:
-
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 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:
- O botão Generate NMI no software de gerenciamento do servidor Lights-Out (iLO) integrado. Este botão é acionado por um usuário.
-
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=10usComo 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
mpirunusando os seguintes parâmetros:
-mca btl openib -mca pml ucx -x UCX_NET_DEVICES=mlx5_ib0
onde,
-
O parâmetro
-mca btl openibdesactivao openib BTL -
O parâmetro
-mca pml ucxconfigura o MPI ABERTO para usaro ucxPML. -
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
mpirunusando 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)
