Red Hat Summit6.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 ...
...
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
# 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
# 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
# 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]
[ 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:
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
mpirunusando os seguintes parâmetros:
-mca btl openib -mca pml ucx -x UCX_NET_DEVICES=mlx5_ib0
-mca btl openib -mca pml ucx -x UCX_NET_DEVICES=mlx5_ib0onde,
-
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
-mca pml_ucx_priority 5Como resultado, a biblioteca OPEN MPI é capaz de escolher uma camada alternativa de transporte disponível sobre a UCX.
(BZ#186666402)
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}