1 .. SPDX-License-Identifier: GPL-2.0
3 .. include:: ../disclaimer-zh_TW.rst
5 :Original: :doc:`../../../admin-guide/bug-hunting`
9 吳想成 Wu XiangCheng <bobwxc@email.cn>
10 胡皓文 Hu Haowen <src.res@email.cn>
17 ------------[ cut here ]------------
18 WARNING: CPU: 1 PID: 28102 at kernel/module.c:1108 module_put+0x57/0x70
19 Modules linked in: dvb_usb_gp8psk(-) dvb_usb dvb_core nvidia_drm(PO) nvidia_modeset(PO) snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd soundcore nvidia(PO) [last unloaded: rc_core]
20 CPU: 1 PID: 28102 Comm: rmmod Tainted: P WC O 4.8.4-build.1 #1
21 Hardware name: MSI MS-7309/MS-7309, BIOS V1.12 02/23/2009
22 00000000 c12ba080 00000000 00000000 c103ed6a c1616014 00000001 00006dc6
23 c1615862 00000454 c109e8a7 c109e8a7 00000009 ffffffff 00000000 f13f6a10
24 f5f5a600 c103ee33 00000009 00000000 00000000 c109e8a7 f80ca4d0 c109f617
26 [<c12ba080>] ? dump_stack+0x44/0x64
27 [<c103ed6a>] ? __warn+0xfa/0x120
28 [<c109e8a7>] ? module_put+0x57/0x70
29 [<c109e8a7>] ? module_put+0x57/0x70
30 [<c103ee33>] ? warn_slowpath_null+0x23/0x30
31 [<c109e8a7>] ? module_put+0x57/0x70
32 [<f80ca4d0>] ? gp8psk_fe_set_frontend+0x460/0x460 [dvb_usb_gp8psk]
33 [<c109f617>] ? symbol_put_addr+0x27/0x50
34 [<f80bc9ca>] ? dvb_usb_adapter_frontend_exit+0x3a/0x70 [dvb_usb]
35 [<f80bb3bf>] ? dvb_usb_exit+0x2f/0xd0 [dvb_usb]
36 [<c13d03bc>] ? usb_disable_endpoint+0x7c/0xb0
37 [<f80bb48a>] ? dvb_usb_device_exit+0x2a/0x50 [dvb_usb]
38 [<c13d2882>] ? usb_unbind_interface+0x62/0x250
39 [<c136b514>] ? __pm_runtime_idle+0x44/0x70
40 [<c13620d8>] ? __device_release_driver+0x78/0x120
41 [<c1362907>] ? driver_detach+0x87/0x90
42 [<c1361c48>] ? bus_remove_driver+0x38/0x90
43 [<c13d1c18>] ? usb_deregister+0x58/0xb0
44 [<c109fbb0>] ? SyS_delete_module+0x130/0x1f0
45 [<c1055654>] ? task_work_run+0x64/0x80
46 [<c1000fa5>] ? exit_to_usermode_loop+0x85/0x90
47 [<c10013f0>] ? do_fast_syscall_32+0x80/0x130
48 [<c1549f43>] ? sysenter_past_esp+0x40/0x6a
49 ---[ end trace 6ebc60ef3981792f ]---
51 這樣的堆棧跟蹤提供了足夠的信息來識別內核原始碼中發生錯誤的那一行。根據問題的
52 嚴重性,它還可能包含 **「Oops」** 一詞,比如::
54 BUG: unable to handle kernel NULL pointer dereference at (null)
55 IP: [<c06969d4>] iret_exc+0x7d0/0xa59
56 *pdpt = 000000002258a001 *pde = 0000000000000000
57 Oops: 0002 [#1] PREEMPT SMP
60 儘管有 **Oops** 或其他類型的堆棧跟蹤,但通常需要找到出問題的行來識別和處理缺
61 陷。在本章中,我們將參考「Oops」來了解需要分析的各種堆棧跟蹤。
63 如果內核是用 ``CONFIG_DEBUG_INFO`` 編譯的,那麼可以使用文件:
64 `scripts/decode_stacktrace.sh` 。
69 受到汙染或正在加載/卸載的模塊用「(…)」標記,汙染標誌在
70 `Documentation/admin-guide/tainted-kernels.rst` 文件中進行了描述,「正在被加
71 載」用「+」標註,「正在被卸載」用「-」標註。
77 通常,Oops文本由klogd從內核緩衝區讀取,然後交給 ``syslogd`` ,後者將其寫入
78 syslog文件,通常是 ``/var/log/messages`` (取決於 ``/etc/syslog.conf`` )。
79 在使用systemd的系統上,它也可以由 ``journald`` 守護進程存儲,並通過運行
80 ``journalctl`` 命令進行訪問。
82 有時 ``klogd`` 會掛掉,這種情況下您可以運行 ``dmesg > file`` 從內核緩衝區
83 讀取數據並保存它。或者您可以 ``cat /proc/kmsg > file`` ,但是您必須適時
84 中斷以停止傳輸,因爲 ``kmsg`` 是一個「永無止境的文件」。
86 如果機器嚴重崩潰,無法輸入命令或磁碟不可用,那還有三個選項:
88 (1) 手動複製屏幕上的文本,並在機器重新啓動後輸入。很難受,但這是突然崩潰下
89 唯一的選擇。或者你可以用數位相機拍下屏幕——雖然不那麼好,但總比什麼都沒
90 有好。如果消息滾動超出控制台頂部,使用更高解析度(例如 ``vga=791`` )
91 引導啓動將允許您閱讀更多文本。(警告:這需要 ``vesafb`` ,因此對「早期」
95 :ref:`Documentation/admin-guide/serial-console.rst <serial_console>` ),
96 在另一台機器上運行數據機然後用你喜歡的通信程序捕獲輸出。
99 (3) 使用Kdump(參閱 Documentation/admin-guide/kdump/kdump.rst ),使用
100 Documentation/admin-guide/kdump/gdbmacros.txt 中的dmesg gdbmacro從舊內存
106 如果你能指出缺陷在內核原始碼中的位置,則報告缺陷的效果會非常好。這有兩種方法。
107 通常來說使用 ``gdb`` 會比較容易,不過內核需要用調試信息來預編譯。
112 GNU 調試器(GNU debugger, ``gdb`` )是從 ``vmlinux`` 文件中找出OOPS的確切
115 在使用 ``CONFIG_DEBUG_INFO`` 編譯的內核上使用gdb效果最好。可通過運行以下命令
118 $ ./scripts/config -d COMPILE_TEST -e DEBUG_KERNEL -e DEBUG_INFO
120 在用 ``CONFIG_DEBUG_INFO`` 編譯的內核上,你可以直接從OOPS複製EIP值::
122 EIP: 0060:[<c021e50e>] Not tainted VLI
129 如果沒有啓用 ``CONFIG_DEBUG_INFO`` ,則使用OOPS的函數偏移::
131 EIP is at vt_ioctl+0xda8/0x1482
133 並在啓用 ``CONFIG_DEBUG_INFO`` 的情況下重新編譯內核::
135 $ ./scripts/config -d COMPILE_TEST -e DEBUG_KERNEL -e DEBUG_INFO
138 (gdb) l *vt_ioctl+0xda8
139 0x1888 is in vt_ioctl (drivers/tty/vt/vt_ioctl.c:293).
141 289 struct vc_data *vc = NULL;
145 293 if (VT_BUSY(vc_num))
148 296 vc = vc_deallocate(vc_num);
149 297 console_unlock();
154 $1 = {int (struct tty_struct *, unsigned int, unsigned long)} 0xae0 <vt_ioctl>
160 $ gdb drivers/tty/vt/vt_ioctl.o
161 (gdb) l *vt_ioctl+0xda8
166 [<ffffffff8802c8e9>] :jbd:log_wait_commit+0xa3/0xf5
167 [<ffffffff810482d9>] autoremove_wake_function+0x0/0x2e
168 [<ffffffff8802770b>] :jbd:journal_stop+0x1be/0x1ee
171 這表明問題可能在 :jbd: 模塊中。您可以在gdb中加載該模塊並列出相關代碼::
174 (gdb) l *log_wait_commit+0xa3
178 您還可以對堆棧跟蹤處的任何函數調用執行相同的操作,例如::
180 [<f80bc9ca>] ? dvb_usb_adapter_frontend_exit+0x3a/0x70 [dvb_usb]
182 上述調用發生的位置可以通過以下方式看到::
184 $ gdb drivers/media/usb/dvb-usb/dvb-usb.o
185 (gdb) l *dvb_usb_adapter_frontend_exit+0x3a
190 要調試內核,請使用objdump並從崩潰輸出中查找十六進位偏移,以找到有效的代碼/匯
191 編行。如果沒有調試符號,您將看到所示例程的彙編程序代碼,但是如果內核有調試
192 符號,C代碼也將可見(調試符號可以在內核配置菜單的hacking項中啓用)。例如::
194 $ objdump -r -S -l --disassemble net/dccp/ipv4.o
198 您需要處於內核樹的頂層以便此獲得您的C文件。
200 如果您無法訪問原始碼,仍然可以使用以下方法調試一些崩潰轉儲(如Dave Miller的
203 EIP is at +0x14/0x4c0
205 Code: 44 24 04 e8 6f 05 00 00 e9 e8 fe ff ff 8d 76 00 8d bc 27 00 00
206 00 00 55 57 56 53 81 ec bc 00 00 00 8b ac 24 d0 00 00 00 8b 5d 08
207 <8b> 83 3c 01 00 00 89 44 24 14 8b 45 28 85 c0 89 44 24 18 0f 85
209 Put the bytes into a "foo.s" file like this:
214 .byte .... /* bytes from Code: part of OOPS dump */
216 Compile it with "gcc -c -o foo.o foo.s" then look at the output of
217 "objdump --disassemble foo.o".
227 mov 0xd0(%esp), %ebp ! %ebp = arg0 (skb)
228 mov 0x8(%ebp), %ebx ! %ebx = skb->sk
229 mov 0x13c(%ebx), %eax ! %eax = inet_sk(sk)->opt
231 `scripts/decodecode` 文件可以用來自動完成大部分工作,這取決於正在調試的CPU
237 一旦你通過定位缺陷找到了其發生的地方,你可以嘗試自己修復它或者向上游報告它。
239 爲了向上游報告,您應該找出用於開發受影響代碼的郵件列表。這可以使用 ``get_maintainer.pl`` 。
242 例如,您在gspca的sonixj.c文件中發現一個缺陷,則可以通過以下方法找到它的維護者::
244 $ ./scripts/get_maintainer.pl -f drivers/media/usb/gspca/sonixj.c
245 Hans Verkuil <hverkuil@xs4all.nl> (odd fixer:GSPCA USB WEBCAM DRIVER,commit_signer:1/1=100%)
246 Mauro Carvalho Chehab <mchehab@kernel.org> (maintainer:MEDIA INPUT INFRASTRUCTURE (V4L/DVB),commit_signer:1/1=100%)
247 Tejun Heo <tj@kernel.org> (commit_signer:1/1=100%)
248 Bhaktipriya Shridhar <bhaktipriya96@gmail.com> (commit_signer:1/1=100%,authored:1/1=100%,added_lines:4/4=100%,removed_lines:9/9=100%)
249 linux-media@vger.kernel.org (open list:GSPCA USB WEBCAM DRIVER)
250 linux-kernel@vger.kernel.org (open list)
254 - 最後接觸原始碼的開發人員(如果這是在git樹中完成的)。在上面的例子中是Tejun
255 和Bhaktipriya(在這個特定的案例中,沒有人真正參與這個文件的開發);
256 - 驅動維護人員(Hans Verkuil);
257 - 子系統維護人員(Mauro Carvalho Chehab);
258 - 驅動程序和/或子系統郵件列表(linux-media@vger.kernel.org);
259 - Linux內核郵件列表(linux-kernel@vger.kernel.org)。
261 通常,修復缺陷的最快方法是將它報告給用於開發相關代碼的郵件列表(linux-media
264 如果你完全不知道該把報告寄給誰,且 ``get_maintainer.pl`` 也沒有提供任何有用
265 的信息,請發送到linux-kernel@vger.kernel.org。
267 感謝您的幫助,這使Linux儘可能穩定:-)
272 如果你懂得編程,你不僅可以通過報告錯誤來幫助我們,還可以提供一個解決方案。
273 畢竟,開源就是分享你的工作,你不想因爲你的天才而被認可嗎?
275 如果你決定這樣做,請在制定解決方案後將其提交到上游。
278 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>` ,
282 ---------------------------------------------------------------------------
284 用 ``klogd`` 進行Oops跟蹤的注意事項
285 ------------------------------------
287 爲了幫助Linus和其他內核開發人員, ``klogd`` 對保護故障的處理提供了大量支持。
288 爲了完整支持地址解析,至少應該使用 ``sysklogd`` 包的1.3-pl3版本。
290 當發生保護故障時, ``klogd`` 守護進程會自動將內核日誌消息中的重要地址轉換爲
291 它們的等效符號。然後通過 ``klogd`` 使用的任何報告機制來轉發這個已翻譯的內核
292 消息。保護錯誤消息可以直接從消息文件中剪切出來並轉發給內核開發人員。
294 ``klogd`` 執行兩種類型的地址解析,靜態翻譯和動態翻譯。靜態翻譯使用System.map
295 文件。爲了進行靜態轉換, ``klogd`` 守護進程必須能夠在守護進程初始化時找到系
296 統映射文件。有關 ``klogd`` 如何搜索映射文件的信息,請參見klogd手冊頁。
298 當使用內核可加載模塊時,動態地址轉換非常重要。由於內核模塊的內存是從內核的
299 動態內存池中分配的,因此無論是模塊的開頭還是模塊中的函數和符號都沒有固定的
302 內核支持系統調用,允許程序確定加載哪些模塊及其在內存中的位置。klogd守護進程
303 使用這些系統調用構建了一個符號表,可用於調試可加載內核模塊中發生的保護錯誤。
305 klogd至少會提供產生保護故障的模塊的名稱。如果可加載模塊的開發人員選擇從模塊
306 導出符號信息,則可能會有其他可用的符號信息。
308 由於內核模塊環境可以是動態的,因此當模塊環境發生變化時,必須有一種通知
309 ``klogd`` 守護進程的機制。有一些可用的命令行選項允許klogd向當前正在執行的守
310 護進程發出信號示意應該刷新符號信息。有關更多信息,請參閱 ``klogd`` 手冊頁。
312 sysklogd發行版附帶了一個補丁,它修改了 ``modules-2.0.0`` 包,以便在加載或
313 卸載模塊時自動向klogd發送信號。應用此補丁基本上可無縫支持調試內核可加載模塊
316 以下是 ``klogd`` 處理的可加載模塊中的保護故障示例::
318 Aug 29 09:51:01 blizard kernel: Unable to handle kernel paging request at virtual address f15e97cc
319 Aug 29 09:51:01 blizard kernel: current->tss.cr3 = 0062d000, %cr3 = 0062d000
320 Aug 29 09:51:01 blizard kernel: *pde = 00000000
321 Aug 29 09:51:01 blizard kernel: Oops: 0002
322 Aug 29 09:51:01 blizard kernel: CPU: 0
323 Aug 29 09:51:01 blizard kernel: EIP: 0010:[oops:_oops+16/3868]
324 Aug 29 09:51:01 blizard kernel: EFLAGS: 00010212
325 Aug 29 09:51:01 blizard kernel: eax: 315e97cc ebx: 003a6f80 ecx: 001be77b edx: 00237c0c
326 Aug 29 09:51:01 blizard kernel: esi: 00000000 edi: bffffdb3 ebp: 00589f90 esp: 00589f8c
327 Aug 29 09:51:01 blizard kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
328 Aug 29 09:51:01 blizard kernel: Process oops_test (pid: 3374, process nr: 21, stackpage=00589000)
329 Aug 29 09:51:01 blizard kernel: Stack: 315e97cc 00589f98 0100b0b4 bffffed4 0012e38e 00240c64 003a6f80 00000001
330 Aug 29 09:51:01 blizard kernel: 00000000 00237810 bfffff00 0010a7fa 00000003 00000001 00000000 bfffff00
331 Aug 29 09:51:01 blizard kernel: bffffdb3 bffffed4 ffffffda 0000002b 0007002b 0000002b 0000002b 00000036
332 Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128]
333 Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3
335 ---------------------------------------------------------------------------
339 Dr. G.W. Wettstein Oncology Research Div. Computing Facility
340 Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com