我有以下锁定。这是否表明slic_test pid 5207是罪犯,或者它只显示,因为内核中的当前宏仍然指向使系统调用到我的驱动程序的用户空间进程?此外 - irq事件标记0 ... irq事件标记到底代表什么?它自启动后不能是中断次数......在88798秒之后肯定超过0 ......
系统是单处理器,禁用CONFIG_SMP。
[88798.449628] BUG: soft lockup - CPU#0 stuck for 61s! [slic_test:5207]
[88798.449628] Modules linked in: slic_xxxx leds_xxxx vortex86_spi dm_mirror dm_log dm_multipath dm_mod ohci_hcd ehci_hcd r6040 vortex86_wdt vortex86_gpio [last un]
[88798.449628] irq event stamp: 0
[88798.449628] hardirqs last enabled at (0): [<00000000>] 0x0
[88798.449628] hardirqs last disabled at (0): [<c0115563>] copy_process+0x233/0x1090
[88798.449628] softirqs last enabled at (0): [<c0115563>] copy_process+0x233/0x1090
[88798.449628] softirqs last disabled at (0): [<00000000>] 0x0
[88798.449628]
[88798.449628] Pid: 5207, comm: slic_test Not tainted (2.6.27.62 #11)
[88798.449628] EIP: 0060:[<c011b6b5>] EFLAGS: 00000246 CPU: 0
[88798.449628] EIP is at __do_softirq+0x45/0xb0
[88798.449628] EAX: 00000000 EBX: 00000082 ECX: 00000001 EDX: dfac5080
[88798.449628] ESI: c0696120 EDI: 0000000a EBP: df3bdf8c ESP: df3bdf80
[88798.449628] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068
[88798.449628] CR0: 8005003b CR2: b7622780 CR3: 1f3c8000 CR4: 00000000
[88798.449628] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[88798.449628] DR6: ffff0ff0 DR7: 00000400
[88798.449628] [<c011b766>] do_softirq+0x46/0x50
[88798.449628] [<c011bad5>] irq_exit+0x45/0x50
[88798.449628] [<c01057ba>] do_IRQ+0x4a/0x90
[88798.449628] [<c0103e68>] common_interrupt+0x28/0x30
[88798.449628] =======================
答案 0 :(得分:4)
呼叫追踪的存在/不存在表示软锁定的来源。
[88798.449628] [<c011b766>] do_softirq+0x46/0x50
[88798.449628] [<c011bad5>] irq_exit+0x45/0x50
[88798.449628] [<c01057ba>] do_IRQ+0x4a/0x90
[88798.449628] [<c0103e68>] common_interrupt+0x28/0x30
Linux内核导致上述调用跟踪所述的上述软锁定。
如果用户空间进程导致软锁定,则会记录通过其 pid 标识进程的行,然后记录各种CPU寄存器的内容而不调用 - 任何种类的痕迹。
答案 1 :(得分:-3)
[88798.449628] Pid:5207,comm:slic_test 没有污染(2.6.27.62#11)
没有污染意味着内核发生了问题。
&#34;被感染的&#34; flags是内核的方式,它说它不是内核错误(内核源是开放的,纯粹的&#34;。#34; Taint&#34;来自非GPL模块和其他。
http://www.opensourceforu.com/2011/01/understanding-a-kernel-oops/