如何区分内核的软locking和用户空间的softlockup?

我有下面的locking。 这是否表明slic_test pid 5207是罪犯,还是仅仅是因为内核中的当前macros仍然指向将系统调用到我的驱动程序中的用户空间进程? 此外 – 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] ======================= 

呼叫跟踪的存在/不存在指示软锁定的起源。

 [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寄存器的内容,而没有任何类型的调用跟踪。

[88798.449628] Pid:5207,comm:slic_test 没有污染 (2.6.27.62#11)

没有污染意味着在内核发生问题。

“感染”标志是内核说它不是内核故障的方式(内核源是开放的,“纯”的),“Taint”来自非GPL模块等等。

http://www.opensourceforu.com/2011/01/understanding-a-kernel-oops/