Kernel Panic

Ada satu layar yang paling ditakuti pengguna Linux: seluruh tampilan membeku, lalu deretan teks putih membanjiri layar hitam, dan mesin berhenti total — tak merespons tombol apa pun. Itulah kernel panic: momen kernel menyadari dirinya berada di kondisi yang tak bisa dipulihkan, lalu memilih berhenti sepenuhnya demi melindungi data daripada terus berjalan dalam keadaan korup. Kabar baiknya, panic jarang acak — hampir selalu ada pola, dan pesan yang tertinggal di layar adalah peta menuju penyebabnya. Chapter ini membedah anatomi pesan panic, penyebab paling umumnya, dan prosedur penyelidikannya dari log boot.

Panic versus Oops #

Dua istilah ini sering tertukar padahal nasibnya berlawanan. Saat kode kernel menemui kesalahan — driver mengakses memori yang salah, misalnya — kernel terlebih dahulu melepaskan sebuah oops: informasi kerusakan dicetak, proses yang bersalah dihentikan, dan kernel menandai dirinya tainted namun tetap berjalan. Sistem yang bertahan dari oops sering tampak normal, tetapi ia berjalan dengan luka — driver yang bersangkutan bisa mati, dan oops berikutnya bisa datang tanpa peringatan.

Panic adalah keputusan yang lebih keras: kernel menyimpulkan kondisinya terlalu parah untuk dipercaya — kerusakan terjadi di interrupt context, struktur data inti rusak, atau memori habis tanpa jalan keluar — sehingga sinkronisasi dihentikan (not syncing) dan seluruh CPU dibekukan. Itulah mengapa layar berhenti persis di tempat: bukan sistem lagi berpikir, melainkan sistem sudah memilih berhenti. Batas antara user space dan kernel space tempat semua ini terjadi sudah kita bahas di Kernel dan Kernel Modules .

Anatomi Pesan Panic #

Dump panic memang membingungkan pada pandangan pertama, tetapi hanya beberapa jenis baris yang benar-benar menentukan. Kita pakai potongan dump asli — disimpan sebagai fixture panic-dump.txt — lalu kita bedah:

cat > panic-dump.txt <<'AKHIR'
CPU: 3 UID: 1000 PID: 4712 Comm: analisis.py Tainted: G      W  O
Hardware name: Lenovo ThinkPad T450s/20BX-CTO1, BIOS 1.50
RIP: 0010:brcmfmac_chip_attach+0x1f2/0x2b0 [brcmfmac]
Code: 48 89 c6 48 8b 07 a9 00 00 01 00 75 f0 48
Call Trace:
 <TASK>
 brcmf_fweh_event_worker+0x1a4/0x2c0 [brcmfmac]
 cfg80211_mlme_send_registrations+0x2c/0xd0 [cfg80211]
 process_one_work+0x1b9/0x360
 worker_thread+0x49/0x300
 </TASK>
Kernel panic - not syncing: Fatal exception in interrupt
AKHIR
grep -E '^(CPU|Hardware name|RIP|Kernel panic)' panic-dump.txt

Output yang Dihasilkan:

CPU: 3 UID: 1000 PID: 4712 Comm: analisis.py Tainted: G      W  O
Hardware name: Lenovo ThinkPad T450s/20BX-CTO1, BIOS 1.50
RIP: 0010:brcmfmac_chip_attach+0x1f2/0x2b0 [brcmfmac]
Kernel panic - not syncing: Fatal exception in interrupt

Empat baris hasil saringan itu adalah kartu identitas insiden:

1. Baris CPU: — proses dan konteks kejadian: PID 4712 milik analisis.py sedang berjalan di CPU 3. Taint W (warning pernah terjadi) dan O (modul out-of-tree termuat) sudah mengarahkan curiga ke kode pihak ketiga.
2. Baris Hardware name: — mesin dan versi BIOS: korban yang sama di mesin berbeda = sinyal faktor lingkungan.
3. Baris RIP: — alamat instruksi yang sedang berjalan saat kerusakan terjadi, lengkap dengan nama fungsi dan, yang paling penting, nama modul dalam kurung siku: [brcmfmac]. Inilah tersangka utamanya — driver wifi Broadcom.
4. Baris Kernel panic — vonisnya: fatal exception in interrupt berarti kerusakan terjadi di tengah penanganan interrupt, konteks yang tidak bisa dipulihkan dengan sekadar menghentikan proses.

Dua baris Call Trace yang tidak ikut tersaring justru cerita kedua: daftar fungsi yang sedang berjalan berlapis saat kerusakan terjadi — seperti daftar keduapan di TKP. Entri dengan akhiran [modul] adalah modul pihak ketiga di jalur itu; fungsi kernel murni (process_one_work, worker_thread) hanyalah kurir yang kebetulan melintas.

Menyisir Call Trace untuk Mencari Modul #

Karena modul dalam kurung siku itulah kode yang bukan bawaan kernel, menyaringnya otomatis memberi kita daftar tersangka. Fixture panic-dump.txt juga tersedia sebagai berkas pendukung di bundle chapter ini, sehingga blok-blok berikut tetap bisa dijalankan sendiri:

sed -n '/Call Trace/,/<\/TASK>/p' panic-dump.txt | grep -o '\[[a-z0-9_]*\]' | sort -u

Output yang Dihasilkan:

[brcmfmac]
[cfg80211]

Perintah tiga lapis ini layak dibedah: sed -n '/Call Trace/,/<\/TASK>/p' memotong hanya potongan antara dua penanda itu, grep -o mengeluarkan setiap potongan yang cocok dengan pola [nama], dan sort -u membuang duplikat. Hasilnya dua nama: brcmfmac dan cfg80211 — dua-duanya bagian dari tumpukan wifi. Peta ini bisa dibawa lebih jauh menjadi skrip pemeta tersangka:

cat > petakan.sh <<'AKHIR'
#!/bin/bash
# Petakan modul di call trace panic ke arah penyelidikan.
modul=$(sed -n '/Call Trace/,/<\/TASK>/p' panic-dump.txt | grep -o '\[[a-z0-9_]*\]' | tr -d '[]' | sort -u | tr '\n' ' ')
for m in $modul; do
  echo "modul di jalur kerusakan : $m"
done
case " $modul " in
  *" brcmfmac "*|*" cfg80211 "*|*" iwlwifi "*)
    echo "arah : driver wifi — periksa firmware, coba nonaktifkan modulnya" ;;
  *" nvidia "*|*" nouveau "*|*" i915 "*)
    echo "arah : driver GPU — periksa DKMS dan versi modul" ;;
  *)
    echo "arah : tak spesifik — uji RAM dengan memtest86+" ;;
esac
AKHIR
bash petakan.sh

Output yang Dihasilkan:

modul di jalur kerusakan : brcmfmac
modul di jalur kerusakan : cfg80211
arah : driver wifi — periksa firmware, coba nonaktifkan modulnya

Skrip ini bukan ramalan — ia hanya memetakan temuan ke langkah penyelidikan berikutnya. Pipa tr '\n' ' ' di baris ke-4 menjaga daftar modul tetap satu baris berkata-spasi sehingga pola case bisa mengujinya, sementara for m in $modul tetap memecahnya per modul. Cabang memtest86+ pada pola yang tak dikenali penting: panic yang tidak menunjuk modul mana pun, dan lokasi kerusakannya berpindah-pindah antar kejadian, adalah pola klasik RAM yang rusak.

Penyebab Paling Umum dan Polanya #

Baris keempat menyambung langsung ke Hardware Compatibility : modul DKMS yang tertinggal setelah update kernel tidak selalu tampil cantik sebagai driver gagal — kadang ia meledak sebagai panic. Pengujian RAM dengan memtest86+ biasanya tersedia sebagai entri di menu boot atau live USB.

Panic saat Boot versus saat Berjalan #

Panic yang terjadi sebelum sistem sempat masuk lebih mudah ditangani daripada kelihatannya, karena kita punya satu pengaman: kernel lama yang masih terpasang. Menu GRUB menyimpannya di bawah Advanced options — pilih entri kernel sebelumnya, dan sistem yang tadinya mati total hidup kembali untuk diperbaiki dengan tenang; teknik menelusuri kegagalan boot dibahas tuntas di Boot Failures . Dari dalam kernel lama itu, dua perbaikan paling sering: bangun ulang modul yang tertinggal lewat DKMS, dan regenerasi initramfs dengan update-initramfs -u -k all agar image boot memuat modul yang benar — anatomi initramfs dibedah di Initramfs .

Panic saat sistem sedang berjalan meninggalkan jejak yang harus dicari setelah reboot: journalctl -b -1 -p err membuka log boot sebelumnya, dan /var/crash menampung dump yang ditangkap kdump bila alat itu terpasang. Satu kejujuran teknis perlu diakui: panic menghentikan sinkronisasi disk, sehingga beberapa baris terakhir kadang tidak sempat tersimpan — kamera ponsel dari awal tadi tetap tak tergantikan. Untuk server tanpa pengawas, parameter kernel panic=N membuat mesin me-restart sendiri N detik setelah panic; kombinasi standarnya menambahkan oops=panic agar oops pun diperlakukan mematikan — keduanya didokumentasikan di parameter kernel .

Ketika sistem sudah tidak bisa diboot dengan kernel mana pun, atau perbaikan menuntut alat di luar instalasi yang rusak, satu jalan tersisa: memindahkan ruang kerja ke live USB dan memperbaiki sistem dari luar — prosedur penyelamatan itulah penutup section ini.

Penyebab dan prosedur penanganannya dirangkum di wiki Arch: Kernel panics , sedangkan opsi panic= dan kawan-kawannya dibaca di kernel-parameters .