ການແກ້ໄຂບັນຫາ

Brandon Nielsen, Jibec Version unknown Last review: 2021-02-22

ເຄີເນີນ (Kernel) ກໍຄືກັນກັບຊອບແວອື່ນໆ ທີ່ອາດມີບັກ (bugs). ມັນເປັນໂຄງການທີ່ໃຫຍ່, ຊັບຊ້ອນ ແລະ ອາດຈະຍາກໃນການຊອກຫາສາເຫດຂອງບັນຫາ. ເອກະສານສະບັບນີ້ຈະແນະນຳເຕັກນິກພື້ນຖານໃນການແກ້ໄຂບັນຫາ ເພື່ອຊ່ວຍຊອກຫາຕົ້ນເຫດຂອງບັນຫາໃຫ້ແຄບເຂົ້າ.

ການບູດເຄື່ອງບໍ່ຂຶ້ນ

ບາງຄັ້ງ ເຄີເນີນອາດຈະບູດບໍ່ຂຶ້ນ. ເຊິ່ງຂຶ້ນຢູ່ກັບວ່າບັນຫາເກີດຂຶ້ນຢູ່ຂັ້ນຕອນໃດຂອງການບູດ, ມັນອາດຈະມີ ຫຼື ບໍ່ມີຂໍ້ຄວາມສະແດງອອກມາເລີຍກໍໄດ້. ນີ້ຄືບາງຂັ້ນຕອນພື້ນຖານທີ່ຄວນເຮັດ:

  • ລຶບ quiet (ເພື່ອໃຫ້ສະແດງຂໍ້ຄວາມ log ຫຼາຍຂຶ້ນ) ແລະ rhgb (ເພື່ອປິດການບູດແບບກຣາຟິກ) ອອກຈາກ boot flags. ຖ້າຂໍ້ຄວາມທີ່ສະແດງອອກມານັ້ນໄວເກີນໄປຈົນອ່ານບໍ່ທັນ, ໃຫ້ຕື່ມ boot_delay=1000 (ເປັນຈຳນວນມິນລິວິນາທີທີ່ຈະໃຫ້ໜ່ວງເວລາໃນລະຫວ່າງ printk ຕອນບູດ). ເຈົ້າສາມາດໃຊ້ກ້ອງຖ່າຍຮູບເພື່ອຖ່າຍຮູບຂໍ້ຄວາມທີ່ສະແດງອອກມານັ້ນໄວ້ໄດ້.

  • ການບູດດ້ວຍ vga=791 (ຫຼື ແມ້ແຕ່ vga=1 ຖ້າກາດຈໍບໍ່ຮອງຮັບ 791) ຈະເຮັດໃຫ້ framebuffer ຢູ່ໃນໂໝດຄວາມລະອຽດສູງ ເພື່ອໃຫ້ສະແດງຂໍ້ຄວາມໄດ້ຫຼາຍແຖວຂຶ້ນໃນໜ້າຈໍ, ເຊິ່ງຈະຊ່ວຍໃຫ້ເຫັນຂໍ້ມູນຫຼາຍຂຶ້ນໃນການວິເຄາະບັກ.

  • ເພີ່ມພາຣາມິເຕີ initcall_debug, ເຊິ່ງຈະຕິດຕາມການເຮັດວຽກຂອງ initcalls ໃນຂະນະທີ່ພວກມັນຖືກປະຕິບັດການ.

  • ຖ້າເຈົ້າບໍ່ເຫັນຂໍ້ຄວາມໃດໆເລີຍຈາກເຄີເນີນ, ການບູດດ້ວຍ earlyprintk=vga ບາງຄັ້ງອາດຈະຊ່ວຍໃຫ້ເຫັນຂໍ້ມູນທີ່ເປັນປະໂຫຍດໄດ້.

ອາການເຄື່ອງຄ້າງ ແລະ ຢຸດເຮັດວຽກ

  • ການກວດສອບວ່າປຸ່ມ CapsLock (ຫຼື NumLock ຫຼື ScrollLock) ເຮັດໃຫ້ ໄຟຢູ່ຄີບອດປ່ຽນສະຖານະຫຼືບໍ່ ນັ້ນສາມາດໃຊ້ເປັນສິ່ງບົ່ງບອກໄດ້ວ່າ ເຄີເນີນຄ້າງໄປເລີຍ ຫຼື ວ່າມີບັນຫາຢ່າງອື່ນເກີດຂຶ້ນ.

  • ປຸ່ມ SysRq magic ອາດຈະຍັງໃຊ້ງານໄດ້. ເຈົ້າອາດຈະຕ້ອງຕື່ມ sysrq_always_enabled=1 ໃສ່ໃນ kernel boot command line. ເບິ່ງລາຍລະອຽດການໃຊ້ງານໄດ້ທີ່ ບົດຄວາມ wiki ກ່ຽວກັບ SysRq.

  • ການຕັ້ງຄ່າ nmi_watchdog=1 ໃນ kernel command line ຈະເຮັດໃຫ້ເກີດການ panic ເມື່ອເກີດ NMI watchdog timeout.

Log ທີ່ຄວນເກັບກຳ

ເມື່ອລາຍງານບັນຫາກ່ຽວກັບເຄີເນີນ, ເຈົ້າຄວນແນບ kernel logs ໄປນຳສະເໝີ, ເຊິ່ງປົກກະຕິແລ້ວຈະເກັບກຳດ້ວຍຄຳສັ່ງ dmesg. ສຳລັບບາງປະເພດຂອງບັນຫາ, ເຈົ້າອາດຈະຕ້ອງເກັບກຳ log ໃຫ້ຫຼາຍກວ່ານີ້.

ບັນຫາການປ້ອນຂໍ້ມູນ (touchpad ແລະ ອື່ນໆ)

ຂໍ້ມູນສຳລັບການເກັບກຳ log ແມ່ນມີບອກໄວ້ຢູ່ໃນ ເວັບໄຊ libinput.

ບັນຫາເລື່ອງສຽງ

alsa-info.sh ໃຫ້ຂໍ້ມູນທັງໃນສ່ວນຂອງເຄີເນີນ ແລະ ສ່ວນປະກອບຂອງ userspace. ຖ້າເຈົ້າມີເຄີເນີນລຸ້ນທີ່ໃຊ້ງານໄດ້ ແລະ ລຸ້ນທີ່ໃຊ້ງານບໍ່ໄດ້, ເຈົ້າຄວນສົ່ງຂໍ້ມູນຈາກ alsa-info.sh ຂອງທັງສອງກໍລະນີ.

ການໃຊ້ Bisect ເພື່ອຫາຈຸດບົກພ່ອງໃນເຄີເນີນ

ຖ້າບັນຫາທີ່ເຈົ້າພົບບໍ່ມີຢູ່ໃນເຄີເນີນລຸ້ນເກົ່າ, ມັນຈະເປັນປະໂຫຍດຫຼາຍຖ້າໃຊ້ git-bisect ເພື່ອຊອກຫາ commit ທີ່ເປັນຕົ້ນເຫດຂອງບັນຫາ. ສຳລັບພາບລວມຂອງ git-bisect, ໃຫ້ເບິ່ງທີ່ ເອກະສານແນະນຳ. ສ່ວນວິທີການ bisect ເຄີເນີນແມ່ນມີຢູ່ໃນ ເອກະສານຂອງເຄີເນີນ. ຄູ່ມືນີ້ຈະມີລາຍລະອຽດສະເພາະສຳລັບ Fedora.

ການ Bisect ເປັນວຽກທີ່ໃຊ້ເວລາຫຼາຍ, ແຕ່ວ່າມັນກົງໄປກົງມາ ແລະ ມັກຈະເປັນວິທີທີ່ດີທີ່ສຸດໃນການຫາສາເຫດຂອງບັນຫາ. ຖ້າເຈົ້າຕ້ອງການໃຫ້ບັນຫາທີ່ເຈົ້າພົບໄດ້ຮັບການແກ້ໄຂແທ້ໆ, ການ bisect ຈະຊ່ວຍເລັ່ງຂະບວນການໃຫ້ໄວຂຶ້ນຫຼາຍໃນເກືອບທຸກກໍລະນີ.

  1. ຊອກຫາລຸ້ນໃໝ່ລ່າສຸດທີ່ຍັງໃຊ້ງານໄດ້. ນີ້ຈະເປັນລຸ້ນ "good" (ດີ) ໃນຕອນເລີ່ມຕົ້ນ. ສ່ວນລຸ້ນທຳອິດທີ່ເຈົ້າພົບວ່າໃຊ້ງານບໍ່ໄດ້ ຈະເປັນລຸ້ນ "bad" (ບໍ່ດີ) ໃນຕອນເລີ່ມຕົ້ນ.

  2. ຕິດຕັ້ງ ສິ່ງທີ່ຈຳເປັນຕ້ອງໃຊ້ (dependencies) ທີ່ຕ້ອງການສຳລັບການບິວ (build) ເຄີເນີນ.

  3. ຕໍ່ໄປ, ດາວໂຫຼດຊອດໂຄ້ດ (source code).

  4. ກຽມໄຟລ໌ .config. ໂດຍສົມມຸດວ່າເຈົ້າໄດ້ຕິດຕັ້ງທັງເຄີເນີນລຸ້ນທີ່ດີ ແລະ ບໍ່ດີໄວ້ແລ້ວ, ໄຟລ໌ config ຂອງທັງສອງຈະຢູ່ໃນ /boot/.[1]

  5. ເລີ່ມຕົ້ນ git-bisect ໃໝ່ດ້ວຍຄຳສັ່ງ git bisect start.

  6. ກຳນົດລຸ້ນໃໝ່ລ່າສຸດທີ່ໃຊ້ງານໄດ້ໃຫ້ເປັນ "good" ດ້ວຍຄຳສັ່ງ git bisect good <tag>. ຕົວຢ່າງ: git bisect good v4.16.8.

  7. ກຳນົດລຸ້ນທຳອິດທີ່ໃຊ້ງານບໍ່ໄດ້ໃຫ້ເປັນ "bad" ດ້ວຍຄຳສັ່ງ git bisect bad <tag>. ຕົວຢ່າງ: git bisect bad v4.17.

  8. ບິວ (Build) ເຄີເນີນ. ບາງຄັ້ງ commit ອາດຈະບິວບໍ່ຜ່ານ. ຖ້າເປັນແນວນັ້ນ, ໃຫ້ຂ້າມ commit ນັ້ນໄປດ້ວຍຄຳສັ່ງ git bisect skip.

  9. ຕິດຕັ້ງເຄີເນີນ.

  10. ບູດເຄື່ອງໃໝ່ເຂົ້າສູ່ເຄີເນີນລຸ້ນໃໝ່ ແລະ ທົດລອງເບິ່ງວ່າມັນໃຊ້ງານໄດ້ຫຼືບໍ່.

  11. ຖ້າເຄີເນີນໃໝ່ໃຊ້ງານໄດ້, ໃຫ້ກຳນົດເປັນ good ດ້ວຍ git bisect good. ຖ້າບໍ່ດັ່ງນັ້ນ, ໃຫ້ກຳນົດເປັນ bad ດ້ວຍ git bisect bad.

  12. ເຮັດຊ້ຳ 5 ຂັ້ນຕອນກ່ອນໜ້ານີ້ ຈົນກວ່າເຈົ້າຈະພົບ commit ທີ່ເປັນຕົ້ນເຫດຂອງບັນຫາ.

1. ໃນເວລາທີ່ເຮັດ bisect ລະຫວ່າງລຸ້ນຫຼັກ (ຕົວຢ່າງ: v4.16 ແລະ v4.15), ຕົວເລືອກການຕັ້ງຄ່າໃໝ່ໆຈະຖືກເພີ່ມເຂົ້າ ຫຼື ຖືກລຶບອອກໃນຂະນະທີ່ເຈົ້າເຮັດ bisect. ໂດຍປົກກະຕິແລ້ວ ການເລືອກຄ່າເລີ່ມຕົ້ນ (default) ແມ່ນປອດໄພ.

Want to help? Learn how to contribute to Fedora Docs ›