11.8. 커널


커널의 kdump 메커니즘으로 인해 64K 커널에서 OOM 오류가 발생합니다.

64비트 ARM 아키텍처의 64K 커널 페이지 크기는 4KB 커널보다 더 많은 메모리를 사용합니다. 결과적으로 kdump 로 인해 커널 패닉이 발생하고 메모리 할당이 OOM(메모리 부족) 오류로 인해 실패합니다. 작업에 따라 crashkernel 값을 640MB로 수동으로 구성합니다. 예를 들어 crashkernel= 매개 변수를 crashkernel=2G- :640M 로 설정합니다.

결과적으로 kdump 메커니즘은 설명된 시나리오의 64K 커널에서 실패하지 않습니다.

Bugzilla:2160676[1]

커널 페이지 크기에 따라 종속 항목이 있는 고객 애플리케이션은 4k에서 64k 페이지 크기 커널로 이동할 때 업데이트해야 할 수 있습니다.

RHEL은 4k 및 64k 페이지 크기 커널과 호환됩니다. 4k 커널 페이지 크기에 종속된 고객 애플리케이션은 4k에서 64k 페이지 크기 커널로 이동할 때 업데이트해야 할 수 있습니다. 알려진 인스턴스에는 jemalloc 및 종속 애플리케이션이 포함됩니다.

jemalloc 메모리 al Cryostat 라이브러리는 시스템의 런타임 환경에서 사용되는 페이지 크기에 민감합니다. 라이브러리는 4k 및 64k 페이지 크기 커널(예: --with-lg-page=16 또는 env JEMALLOC_SYS_WITH_LG_PAGE=16 )과 호환되도록 빌드할 수 있습니다. 결과적으로 런타임 환경의 페이지 크기와 jemalloc 에 의존하는 바이너리를 컴파일할 때 존재하는 페이지 크기 간에 불일치가 발생할 수 있습니다. 결과적으로 jemalloc기반 애플리케이션을 사용하면 다음 오류가 트리거됩니다.

<jemalloc>: Unsupported system page size

이 문제를 방지하려면 다음 방법 중 하나를 사용하십시오.

  • 적절한 빌드 구성 또는 환경 옵션을 사용하여 4k 및 64k 페이지 크기 호환 바이너리를 생성합니다.
  • 최종 64k 커널 및 런타임 환경으로 부팅한 후 jemalloc 을 사용하는 사용자 공간 패키지를 빌드합니다.

예를 들어, Rust 패키지 관리자와 함께 jemalloc 도 사용하는 fd-find 툴을 빌드할 수 있습니다. 최종 64k 환경에서 다음을 입력하여 모든 종속 항목의 새 빌드를 트리거하여 페이지 크기의 불일치를 해결합니다.

# cargo install fd-find --force

Bugzilla:2167783[1]

dnf 를 사용하여 최신 실시간 커널로 업그레이드해도 여러 커널 버전이 병렬로 설치되지 않음

dnf 패키지 관리자를 사용하여 최신 실시간 커널을 설치하려면 패키지 종속성을 확인해야 새 커널 버전과 현재 커널 버전을 동시에 유지해야 합니다. 기본적으로 dnf 는 업그레이드 중에 이전 kernel-rt 패키지를 제거합니다.

이 문제를 해결하려면 /etc/yum.conf 구성 파일의 installonlypkgs 옵션에 현재 kernel-rt 패키지를 추가합니다(예: installonlypkgs=kernel-rt ).

installonlypkgs 옵션은 dnf 에서 사용하는 기본 목록에 kernel-rt 를 추가합니다. installonlypkgs 지시문에 나열된 패키지는 자동으로 제거되지 않으므로 동시에 설치할 여러 커널 버전을 지원합니다.

여러 커널이 설치되어 있는 것은 새 커널 버전으로 작업할 때 대체 옵션을 사용하는 방법입니다.

Bugzilla:2181571[1]

지연 계정 기능은 기본적으로 SWAPINIO% 통계 열을 표시하지 않습니다.

초기 버전과 달리 지연된 계정 기능은 기본적으로 비활성화되어 있습니다. 결과적으로 iotop 애플리케이션에 SWAPINIO% 통계 열이 표시되지 않고 다음 경고가 표시됩니다.

CONFIG_TASK_DELAY_ACCT not enabled in kernel, cannot determine SWAPIN and IO%

작업stats 인터페이스를 사용하여 스레드 그룹에 속하는 모든 작업 또는 스레드에 대한 지연 통계를 제공합니다. 작업 실행 지연은 커널 리소스가 제공될 때까지 기다립니다(예: 사용 가능한 CPU가 실행될 때까지 기다리는 작업). 작업의 CPU 우선 순위, I/O 우선 순위 및 rss 제한 값을 적절하게 설정하는 데 도움이 됩니다.

이 문제를 해결하려면 런타임 또는 부팅 시 delayacct 부팅 옵션을 활성화할 수 있습니다.

  • 런타임에 delayacct 를 활성화하려면 다음을 입력합니다.

    echo 1 > /proc/sys/kernel/task_delayacct

    이 명령은 기능 시스템 전체 기능을 활성화하지만 이 명령을 실행한 후에 시작하는 작업에만 적용됩니다.

  • 부팅 시 지연을 영구적으로 활성화하려면 다음 절차 중 하나를 사용합니다.

결과적으로 iotop 애플리케이션에 SWAPINIO% 통계 열이 표시됩니다.

Bugzilla:2132480[1]

코어가 큰 시스템에서 실시간 커널의 하드웨어 인증으로 skew-tick=1 부팅 매개변수를 전달해야 할 수 있습니다.

다수의 소켓과 대규모 코어 개수가 있는 대규모 또는 중간 규모의 시스템은 시간 보관 시스템에 사용되는 xtime_lock 의 잠금 경합으로 인해 대기 시간이 급증할 수 있습니다. 결과적으로 멀티프로세싱 시스템에서 대기 시간이 급증하고 하드웨어 인증 지연이 발생할 수 있습니다. 이 문제를 해결하려면 skew_tick=1 부팅 매개변수를 추가하여 CPU당 타이머 눈금을 다른 시간에 시작할 수 있습니다.

잠금 충돌을 방지하려면 skew_tick=1 을 활성화합니다.

  1. grubby 를 사용하여 skew_tick=1 매개변수를 활성화합니다.

    # grubby --update-kernel=ALL --args="skew_tick=1"
  2. 변경 사항을 적용하려면 재부팅하십시오.
  3. 부팅 중에 전달하는 커널 매개변수를 표시하여 새 설정을 확인합니다.

    cat /proc/cmdline

skew_tick=1 을 활성화하면 전력 소비가 크게 증가하므로 대기 시간에 민감한 실시간 워크로드를 실행하는 경우에만 활성화해야 합니다.

Jira:RHEL-9318[1]

kdump 메커니즘이 LUKS 암호화 대상에서 vmcore 파일을 캡처하지 못했습니다

Linux 통합 키 설정(LUKS) 암호화된 파티션이 있는 시스템에서 kdump 를 실행하는 경우 시스템에 특정 양의 사용 가능한 메모리가 필요합니다. 사용 가능한 메모리가 필요한 메모리 양보다 작으면 systemd-cryptsetup 서비스가 파티션을 마운트하지 못합니다. 결과적으로 두 번째 커널은 LUKS 암호화 대상에서 크래시 덤프 파일을 캡처하지 못합니다.

이 문제를 해결하려면 Recommended crashkernel 값을 쿼리하고 메모리 크기를 적절한 값으로 점진적으로 늘립니다. Recommended crashkernel 값은 필요한 메모리 크기를 설정하는 참조 역할을 할 수 있습니다.

  1. 추정된 크래시 커널 값을 출력합니다.

    # kdumpctl estimate
  2. crashkernel 값을 늘려 필요한 메모리 양을 구성합니다.

    # grubby --args=crashkernel=652M --update-kernel=ALL
  3. 변경 사항을 적용하려면 시스템을 재부팅합니다.

    # reboot

결과적으로 kdump 는 LUKS 암호화 파티션이 있는 시스템에서 올바르게 작동합니다.

Jira:RHEL-11196[1]

kdump 서비스가 IBM Z 시스템에서 initrd 파일을 빌드하지 못했습니다

64비트 IBM Z 시스템에서 s390-subchannels 와 같은 znet 관련 구성 정보가 비활성 NetworkManager 연결 프로필에 있는 경우 kdump 서비스가 초기 RAM 디스크(initrd)를 로드하지 못합니다. 결과적으로 kdump 메커니즘이 다음 오류와 함께 실패합니다.

dracut: Failed to set up znet
kdump: mkdumprd: failed to make kdump initrd

이 문제를 해결하려면 다음 솔루션 중 하나를 사용하십시오.

  • znet 구성 정보가 있는 연결 프로필을 다시 사용하여 네트워크 본딩 또는 브리지를 구성합니다.

    $ nmcli connection modify enc600 master bond0 slave-type bond
  • 비활성 연결 프로필에서 활성 연결 프로필에 znet 구성 정보를 복사합니다.

    1. nmcli 명령을 실행하여 NetworkManager 연결 프로필을 쿼리합니다.

      # nmcli connection show
      
      NAME                       UUID               TYPE   Device
      
      bridge-br0           ed391a43-bdea-4170-b8a2 bridge   br0
      bridge-slave-enc600  caf7f770-1e55-4126-a2f4 ethernet enc600
      enc600               bc293b8d-ef1e-45f6-bad1 ethernet --
    2. 비활성 연결의 구성 정보로 활성 프로필을 업데이트합니다.

      #!/bin/bash
       inactive_connection=enc600
       active_connection=bridge-slave-enc600
       for name in nettype subchannels options; do
       field=802-3-ethernet.s390-$name
       val=$(nmcli --get-values "$field"connection show "$inactive_connection")
       nmcli connection modify "$active_connection" "$field" $val"
       done
    3. 변경 사항을 적용하려면 kdump 서비스를 다시 시작하십시오.

      # kdumpctl restart

Bugzilla:2064708

iwl7260-firmware 는 Intel Wi-Fi 6 AX200, AX210 및 CryostatPad P1 Cryostat 4에서 Wi-Fi를 분리합니다.

iwl7260-firmware 또는 iwl7260-wifi 드라이버를 RHEL 9.1 이상에서 제공하는 버전으로 업데이트한 후 하드웨어가 잘못된 내부 상태가 됩니다. 상태를 잘못 보고합니다. 결과적으로 Intel Wifi 6 카드가 작동하지 않을 수 있으며 오류 메시지가 표시됩니다.

kernel: iwlwifi 0000:09:00.0: Failed to start RT ucode: -110
kernel: iwlwifi 0000:09:00.0: WRT: Collecting data: ini trigger 13 fired (delay=0ms)
kernel: iwlwifi 0000:09:00.0: Failed to run INIT ucode: -110

확인되지 않은 해결 방법은 시스템의 전원을 끄고 다시 켜는 것입니다. 재부팅하지 마십시오.

Bugzilla:2129288[1]

kmod 의 약한 모듈이 모듈 상호 의존과 함께 작동하지 않음

kmod 패키지에서 제공하는 weak-modules 스크립트는 설치된 커널과 kABI와 호환되는 모듈을 결정합니다. 그러나 모듈의 커널 호환성을 확인하는 동안 약한 모듈은 빌드된 커널의 상위 릴리스에서 더 낮은 릴리스까지 종속성을 기호화합니다. 결과적으로 다른 커널 릴리스에 빌드된 상호 종속 관계가 있는 모듈은 호환되지 않는 것으로 해석될 수 있으므로 이 시나리오에서는 weak-modules 스크립트가 작동하지 않을 수 있습니다.

이 문제를 해결하려면 새 커널을 설치하기 전에 최신 커널에 대해 추가 모듈을 빌드하거나 배치하십시오.

Bugzilla:2103605[1]

dkms 는 64비트 ARM CPU에서 올바르게 컴파일된 드라이버를 사용하여 프로그램 오류에 대한 잘못된 경고를 제공합니다.

동적 커널 모듈 지원(dkms) 유틸리티는 64비트 ARM CPU의 커널 헤더가 4 킬로바이트 및 64 킬로바이트 페이지 크기가 있는 커널 모두에서 작동하는지 인식하지 못합니다. 결과적으로 커널 업데이트가 수행되고 kernel-64k-devel 패키지가 설치되지 않은 경우 dkms 는 프로그램이 올바르게 컴파일된 드라이버에서 실패한 이유에 대한 잘못된 경고를 제공합니다. 이 문제를 해결하려면 두 가지 유형의 ARM CPU 아키텍처에 대한 헤더 파일이 포함된 kernel-headers 패키지를 설치하고 dkms 및 해당 요구 사항에 국한되지 않습니다.

JIRA:RHEL-25967[1]

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.