Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1213232
  • 博文数量: 122
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 4002
  • 用 户 组: 普通用户
  • 注册时间: 2014-02-20 08:27
文章分类
文章存档

2016年(1)

2015年(21)

2014年(100)

分类: LINUX

2015-01-10 15:26:40

一、故障现象
内核panic,打印如下:

点击(此处)折叠或打开

  1. Unable to handle kernel NULL pointer dereference at 0000000000000039 RIP:
  2.  [<ffffffff80010b74>] handle_IRQ_event+0x44/0xa6
  3. PGD 61df63067 PUD 61ea5a067 PMD 0
  4. Oops: 0000 [1] SMP
  5. last sysfs file: /devices/system/cpu/cpu0/cpufreq/scaling_max_freq
  6. CPU 8
  7. Modules linked in: ossmod(U) tipc(U) bsp_smbus_ctrl(U) bonding autofs4 hidp rfcomm l2cap bluetooth lockd sunrpc ipv6 xfrm_nalgo crypto_api cpufreq_ondemand acpi_cpufreq freq_table dm_mirror d
  8. m_multipath scsi_dh video hwmon backlight sbs i2c_ec button battery asus_acpi acpi_memhotplug ac lp floppy esh(U) snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_de
  9. vice sg snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_hwdep snd igb i2c_i801 i2c_core soundcore 8021q serio_raw parport_pc parport e1000(U) pcspkr dm_raid45 dm_message dm_reg
  10. ion_hash dm_log dm_mod dm_mem_cache ata_piix libata shpchp mptsas mptscsih mptbase scsi_transport_sas sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
  11. Pid: 0, comm: swapper Tainted: G 2.6.18-164.el5 #1
  12. RIP: 0010:[<ffffffff80010b74>] [<ffffffff80010b74>] handle_IRQ_event+0x44/0xa6
  13. RSP: 0018:ffff81032fca7f28 EFLAGS: 00010202
  14. RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000000000b2
  15. RDX: ffff810009028520 RSI: ffff81032fc98000 RDI: ffff81032b1c7180
  16. RBP: 0000000000000001 R08: ffff81032fca0000 R09: ffffffff800967c5
  17. R10: ffff81032fca7f30 R11: ffff81032fca1ee8 R12: 00000000000000b2
  18. R13: 0000000000000001 R14: ffff81032fca1df8 R15: ffff81032fca1df8
  19. FS: 0000000000000000(0000) GS:ffff81010b373b40(0000) knlGS:0000000000000000
  20. CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
  21. CR2: 0000000000000039 CR3: 000000061f37c000 CR4: 00000000000006e0
  22. Process swapper (pid: 0, threadinfo ffff81032fca0000, task ffff81033ab0f7e0)
  23. Stack: ffffffff803e3580 000000000000b200 00000000000000b2 ffff81032acdee40
  24.  ffffffff803e35bc ffffffff800b9808 ffffffff8001235a 00000000000000b2
  25.  ffff81032fca1df8 00000000009c1418 ffff81062dc4d000 0000000000000800
  26. Call Trace:
  27.  <IRQ> [<ffffffff800b9808>] __do_IRQ+0xa4/0x103
  28.  [<ffffffff8001235a>] __do_softirq+0x89/0x133
  29.  [<ffffffff8006c997>] do_IRQ+0xe7/0xf5
  30.  [<ffffffff8005d615>] ret_from_intr+0x0/0xa
  31.  <EOI> [<ffffffff8019768f>] acpi_processor_idle+0x274/0x463
  32.  [<ffffffff80197685>] acpi_processor_idle+0x26a/0x463
  33.  [<ffffffff8019741b>] acpi_processor_idle+0x0/0x463
  34.  [<ffffffff8019741b>] acpi_processor_idle+0x0/0x463
  35.  [<ffffffff8004939e>] cpu_idle+0x95/0xb8
  36.  [<ffffffff80076e23>] start_secondary+0x45a/0x469

从打印看,是在handle_IRQ_event函数中遇到了空指针


二、Vmcore分析
1、反汇编handle_IRQ_event,获取RIP所在的指令

点击(此处)折叠或打开

  1. crash> dis -l handle_IRQ_event
  2. /usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/kernel/irq/handle.c: 134
  3. 0xffffffff80010b30 <handle_IRQ_event>: push %r14
  4. include/trace/irq.h: 7
  5. 0xffffffff80010b32 <handle_IRQ_event+2>: cmpl $0x0,3859215(%rip) # 0xffffffff803bee48 <__tracepoint_irq_entry.10785+8>
  6. /usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/kernel/irq/handle.c: 134
  7. 0xffffffff80010b39 <handle_IRQ_event+9>: mov %rsi,%r14
  8. 0xffffffff80010b3c <handle_IRQ_event+12>: push %r13
  9. 0xffffffff80010b3e <handle_IRQ_event+14>: push %r12
  10. 0xffffffff80010b40 <handle_IRQ_event+16>: mov %edi,%r12d
  11. 0xffffffff80010b43 <handle_IRQ_event+19>: push %rbp
  12. 0xffffffff80010b44 <handle_IRQ_event+20>: mov %rdx,%rbp
  13. 0xffffffff80010b47 <handle_IRQ_event+23>: push %rbx
  14. include/trace/irq.h: 7
  15. 0xffffffff80010b48 <handle_IRQ_event+24>: je 0xffffffff80010b68 <handle_IRQ_event+56>
  16. 0xffffffff80010b4a <handle_IRQ_event+26>: mov 3859199(%rip),%rbx # 0xffffffff803bee50 <__tracepoint_irq_entry.10785+16>
  17. 0xffffffff80010b51 <handle_IRQ_event+33>: test %rbx,%rbx
  18. 0xffffffff80010b54 <handle_IRQ_event+36>: je 0xffffffff80010b68 <handle_IRQ_event+56>
  19. 0xffffffff80010b56 <handle_IRQ_event+38>: mov %r14,%rsi
  20. 0xffffffff80010b59 <handle_IRQ_event+41>: mov %r12d,%edi
  21. 0xffffffff80010b5c <handle_IRQ_event+44>: callq *(%rbx)
  22. 0xffffffff80010b5e <handle_IRQ_event+46>: add $0x8,%rbx
  23. 0xffffffff80010b62 <handle_IRQ_event+50>: cmpq $0x0,(%rbx)
  24. 0xffffffff80010b66 <handle_IRQ_event+54>: jmp 0xffffffff80010b54 <handle_IRQ_event+36>
  25. /usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/kernel/irq/handle.c: 142
  26. 0xffffffff80010b68 <handle_IRQ_event+56>: testb $0x20,0x8(%rbp)
  27. 0xffffffff80010b6c <handle_IRQ_event+60>: jne 0xffffffff80010b6f <handle_IRQ_event+63>
  28. include/asm/irqflags.h: 80
  29. 0xffffffff80010b6e <handle_IRQ_event+62>: sti
  30. 0xffffffff80010b6f <handle_IRQ_event+63>: xor %r13d,%r13d
  31. 0xffffffff80010b72 <handle_IRQ_event+66>: xor %ebx,%ebx
  32. /usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/kernel/irq/handle.c: 146
  33. 0xffffffff80010b74 <handle_IRQ_event+68>: mov 0x38(%rbp),%rsi
  34. 0xffffffff80010b78 <handle_IRQ_event+72>: mov %r14,%rdx

从之前的堆栈可以看出RIP为:handle_IRQ_event+0x44/0xa6
0x44折算成十进制为68,所以需要关注handle_IRQ_event+68行:
0xffffffff80010b74 :       mov    0x38(%rbp),%rsi
从之前的汇编分析,rsi的值应该是上级函数传入,不太可能在其中出现空指针,问题应该出在0x38(%rbp)上,也就是rbp上。

2、结合handle_IRQ_event源代码分析
handle_IRQ_event代码如下:

点击(此处)折叠或打开

  1. 132 irqreturn_t handle_IRQ_event(unsigned int irq, struct pt_regs *regs,
  2. 133 struct irqaction *action)
  3. 134 {
  4. 135 irqreturn_t ret, retval = IRQ_NONE;
  5. 136 unsigned int status = 0;
  6. 137
  7. 138 trace_irq_entry(irq, regs);
  8. 139
  9. 140 handle_dynamic_tick(action);
  10. 141
  11. 142 if (!(action->flags & IRQF_DISABLED))
  12. 143 local_irq_enable_in_hardirq();
  13. 144
  14. 145 do {
  15. 146 ret = action->handler(irq, action->dev_id, regs);
  16. 147 if (ret == IRQ_HANDLED)
  17. 148 status |= action->flags;
  18. 149 retval |= ret;
  19. 150 action = action->next;
  20. 151 } while (action);
  21. 152
  22. 153 if (status & IRQF_SAMPLE_RANDOM)
  23. 154 add_interrupt_randomness(irq);
  24. 155 local_irq_disable();
  25. 156
  26. 157 trace_irq_exit(irq, retval);
  27. 158
  28. 159 return retval;
  29. 160 }

之前反汇编中有代码行提示:
/usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/kernel/irq/handle.c: 146
可以看出问题出在146行:
146         ret = action->handler(irq, action->dev_id, regs);
可以看出0x38(%rbp)应该对应action->dev_id(因为通过偏移访问,结构体访问基本如此),如此可见rbp中存放的即action变量的的值,
分析源代码,action是通过入参传入的,但是在146-151行的循环中,150行,对action重新赋值了。
150         action = action->next;
如此,可以推测action->next出问题了,也就是通过入参传入的action的next成员出问题了,of course,也可能是一开始的传入的如此就有问题了。
继续分析action入参的值。

3、入参(action)分析
action被放入了rbp寄存器,看如下汇编行:
0xffffffff80010b44 :       mov    %rdx,%rbp
可以看出,action入参是通过rdx寄存器传入的,并不是我们通常认为的通过堆栈。需要进一步分析上级行数中的rdx寄存器的值。

4、上级函数__do_IRQ分析

点击(此处)折叠或打开

  1. crash> bt
  2. PID: 0 TASK: ffff81033ab0f7e0 CPU: 8 COMMAND: "swapper"
  3.  #0 [ffff81032fca7c80] crash_kexec at ffffffff800ac5b9
  4.  #1 [ffff81032fca7d40] __die at ffffffff80065127
  5.  #2 [ffff81032fca7d80] do_page_fault at ffffffff80066da7
  6.  #3 [ffff81032fca7e70] error_exit at ffffffff8005dde9
  7.     [exception RIP: handle_IRQ_event+68]
  8.     RIP: ffffffff80010b74 RSP: ffff81032fca7f28 RFLAGS: 00010202
  9.     RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000000000b2
  10.     RDX: ffff810009028520 RSI: ffff81032fc98000 RDI: ffff81032b1c7180
  11.     RBP: 0000000000000001 R8: ffff81032fca0000 R9: ffffffff800967c5
  12.     R10: ffff81032fca7f30 R11: ffff81032fca1ee8 R12: 00000000000000b2
  13.     R13: 0000000000000001 R14: ffff81032fca1df8 R15: ffff81032fca1df8
  14.     ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
  15.  #4 [ffff81032fca7f20] handle_IRQ_event at ffffffff80010b81
  16.  #5 [ffff81032fca7f50] __do_IRQ at ffffffff800b9808
  17.  #6 [ffff81032fca7f90] do_IRQ at ffffffff8006c997
  18. --- <IRQ stack> ---
可见,上级函数为__do_IRQ。
对照__do_IRQ源代码,可以看出调用handle_IRQ_event的地方为240行,所以关注汇编中的相关行附件代码即可

点击(此处)折叠或打开

  1. 174 fastcall unsigned int __do_IRQ(unsigned int irq, struct pt_regs *regs)
  2. 175 {
  3. 176 struct irq_desc *desc = irq_desc + irq;
  4. 177 struct irqaction *action;
  5. 178 unsigned int status;
  6. ...
  7. 235 for (;;) {
  8. 236 irqreturn_t action_ret;
  9. 237
  10. 238 spin_unlock(&desc->lock);
  11. 239
  12. 240 action_ret = handle_IRQ_event(irq, regs, action);
  13. 241 if (!noirqdebug)
  14. 242 note_interrupt(irq, desc, action_ret, regs);
  15. 243
  16. 244 spin_lock(&desc->lock);
  17. 245 if (likely(!(desc->status & IRQ_PENDING)))
  18. 246 break;
  19. 247 desc->status &= ~IRQ_PENDING;
  20. 248 }
  21. ...
  22. 260 }
继续反汇编__do_IRQ

点击(此处)折叠或打开

  1. /usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/kernel/irq/handle.c: 222
  2. 0xffffffff800b97f1 <__do_IRQ+141>: je 0xffffffff800b9845 <__do_IRQ+225>
  3. include/asm/spinlock.h: 62
  4. 0xffffffff800b97f3 <__do_IRQ+143>: movl $0x1,0x3c(%rbx)
  5. /usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/kernel/irq/handle.c: 240
  6. 0xffffffff800b97fa <__do_IRQ+150>: mov %r13,%rdx
  7. 0xffffffff800b97fd <__do_IRQ+153>: mov %r15,%rsi
  8. 0xffffffff800b9800 <__do_IRQ+156>: mov %r12d,%edi
  9. 0xffffffff800b9803 <__do_IRQ+159>: callq 0xffffffff80010b30 <handle_IRQ_event>
  10. /usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/kernel/irq/handle.c: 241
  11. 0xffffffff800b9808 <__do_IRQ+164>: cmpl $0x0,3358161(%rip) # 0xffffffff803ed5e0 <noirqdebug>
  12. 0xffffffff800b980f <__do_IRQ+171>: jne 0xffffffff800b9821 <__do_IRQ+189>
  13. /usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/kernel/irq/handle.c: 242
  14. 0xffffffff800b9811 <__do_IRQ+173>: mov %r15,%rcx
  15. 0xffffffff800b9814 <__do_IRQ+176>: mov %eax,%edx
  16. 0xffffffff800b9816 <__do_IRQ+178>: mov %rbx,%rsi
  17. 0xffffffff800b9819 <__do_IRQ+181>: mov %r12d,%edi

可以看出edx的值来源于r13,再回看handle_IRQ_event函数的反汇编,在该函数的开始对r13寄存器进行了压栈

点击(此处)折叠或打开

  1. 0xffffffff80010b30 <handle_IRQ_event>: push %r14
  2. include/trace/irq.h: 7
  3. 0xffffffff80010b32 <handle_IRQ_event+2>: cmpl $0x0,3859215(%rip) # 0xffffffff803bee48 <__tracepoint_irq_entry.10785+8>
  4. /usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/kernel/irq/handle.c: 134
  5. 0xffffffff80010b39 <handle_IRQ_event+9>: mov %rsi,%r14
  6. 0xffffffff80010b3c <handle_IRQ_event+12>: push %r13

所以,可以从handle_IRQ_event函数的栈帧中找到action的值。r13应该位于该栈帧中的第3个值,因为第一个必然为函数的返回地址,第二个值为r14(在r13之前压入)。
看看handle_IRQ_event函数的栈

点击(此处)折叠或打开

  1. crash> bt -f
  2. PID: 0 TASK: ffff81033ab0f7e0 CPU: 8 COMMAND: "swapper"
  3.  #0 [ffff81032fca7c80] crash_kexec at ffffffff800ac5b9
  4.     ffff81032fca7c88: ffff81032fca1df8 ffff81032fca1df8
  5.     ffff81032fca7c98: 0000000000000001 00000000000000b2
  6.     ffff81032fca7ca8: 0000000000000001 0000000000000000
  7.     ffff81032fca7cb8: ffff81032fca1ee8 ffff81032fca7f30
  8.     ffff81032fca7cc8: ffffffff800967c5 ffff81032fca0000
  9.     ffff81032fca7cd8: 0000000000000001 00000000000000b2
  10.     ffff81032fca7ce8: ffff810009028520 ffff81032fc98000
  11.     ffff81032fca7cf8: ffff81032b1c7180 ffffffffffffffff
  12.     ffff81032fca7d08: ffffffff80010b74 0000000000000010
  13.     ffff81032fca7d18: 0000000000010202 ffff81032fca7f28
  14.     ffff81032fca7d28: 0000000000000018 ffff81032fca7e78
  15.     ffff81032fca7d38: ffffffff802a4d0d ffffffff80065127
  16. .......
  17. #4 [ffff81032fca7f20] handle_IRQ_event at ffffffff80010b81
  18.     ffff81032fca7f28: ffffffff803e3580 000000000000b200
  19.     ffff81032fca7f38: 00000000000000b2 ffff81032acdee40
  20.     ffff81032fca7f48: ffffffff803e35bc ffffffff800b9808
  21.  #5 [ffff81032fca7f50] __do_IRQ at ffffffff800b9808
  22.     ffff81032fca7f58: ffffffff8001235a 00000000000000b2
  23.     ffff81032fca7f68: ffff81032fca1df8 00000000009c1418
  24.     ffff81032fca7f78: ffff81062dc4d000 0000000000000800
  25.     ffff81032fca7f88: ffffffff803ea360 ffffffff8006c997

可以看出action的值应该为ffff81032acdee40,看看其中的内容,顺便验证下。
action为irqaction类型的结构体:

点击(此处)折叠或打开

  1. crash> struct irqaction ffff81032acdee40
  2. struct irqaction {
  3.   handler = 0xffffffff8827628b,
  4.   flags = 0,
  5.   mask = {
  6.     bits = {0, 0, 0, 0}
  7.   },
  8.   name = 0xffff81032b1c7000 "eth0-rx-3",
  9.   dev_id = 0xffff81032bef56b8,
  10.   next = 0x1,
  11.   irq = 178,
  12.   dir = 0xffff810328db2180
  13. }

可以看出该irqaction结构体对应于eth0网卡的接收中断,中断号为178,注意其中的next,为0x1,这就是问题所在。
从log信息可以看出空指针具体的值为:0000000000000039 ,正好=0x1+38,所以说明分析是正确的。

分析代码逻辑和irqaction的定义:

点击(此处)折叠或打开

  1. crash> struct irqaction
  2. struct irqaction {
  3.     irqreturn_t (*handler)(int, void *, struct pt_regs *);
  4.     long unsigned int flags;
  5.     cpumask_t mask;
  6.     const char *name;
  7.     void *dev_id;
  8.     struct irqaction *next;
  9.     int irq;
  10.     struct proc_dir_entry *dir;
  11. }
  12. SIZE: 88

这里的next应该在有中断共享时使用,即同一个irq号对应多个ISR,如果有共享,那么这里的next指向共享该irq的下一个action.
从/proc/interrupts信息,可以看出178号中断并没有共享的情况,所以,这里的next应该为null,为0x1显然有问题了。
从irqaction中的值分析,next前后的数据都是正常的,只有next从0突变成1了,基本可以排除由于内存越界导致内存写坏的情况。
分析设置next指针的所有代码,只有设置地址和删除的代码,并没有发现有直接设置为1的地方。

那为什么如此呢?要继续分析就很困难了。

5、分析irq_desc
没有其它分析思路了,尝试分析action所在的结构体irq_desc,看看其中的内容,该结构体的值需要从上级函数__do_IRQ分析,见其代码176行:
176     struct irq_desc *desc = irq_desc + irq;
其中irq_desc为全局变量(数组),存放所有的irq_desc,按编号排列。
对照其汇编:
/usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/kernel/irq/handle.c: 176
0xffffffff800b9784 <__do_IRQ+32>:       lea    0xffffffff803d8380(%rbp),%rbx
lea指令的意思是将0xffffffff803d8380(%rbp)地址(即rbp+0xffffffff803d8380),赋值给rbx,这里显然0xffffffff803d8380就是irq_desc全局变量的地址。
确认一下:

点击(此处)折叠或打开

  1. crash> struct irq_desc 0xffffffff803d8380
  2. struct irq_desc {
  3.   handle_irq = 0,
  4.   chip = 0xffffffff803ec7e0,
  5.   handler_data = 0x0,
  6.   chip_data = 0x0,
  7.   action = 0xffffffff803018a0,
  8.   status = 0,
  9.   depth = 0,
  10.   wake_depth = 0,
  11.   irq_count = 22386,
  12.   irqs_unhandled = 0,
  13.   lock = {
  14.     raw_lock = {
  15.       slock = 1
  16.     }
  17.   },
  18.   affinity = {
  19.     bits = {1, 0, 0, 0}
  20.   },
  21.   cpu = 0,
  22.   pending_mask = {
  23.     bits = {0, 0, 0, 0}
  24.   },
  25.   move_irq = 0,
  26.   dir = 0xffff81062ddbd180
  27. }
  28. crash> struct irqaction 0xffffffff803018a0
  29. struct irqaction {
  30.   handler = 0xffffffff8006e9da <timer_interrupt>,
  31.   flags = 32,
  32.   mask = {
  33.     bits = {0, 0, 0, 0}
  34.   },
  35.   name = 0xffffffff802b3dfa "timer",
  36.   dev_id = 0x0,
  37.   next = 0x0,
  38.   irq = 0,
  39.   dir = 0x0
  40. }

可以看出位于该全局变量的第一个元素为时钟中断对应的描述符,说明分析正确。但我们这里需要分析的是178号中断(irq好前面已经分析得到了),应该怎么查找呢。
继续看汇编代码,可以看出178号中断对应的描述符在irq_desc数组中的偏移量存放在rbp中了,查看rbp后续的汇编代码,并没有对进行压栈处理,且当前函数不是最顶级的堆栈函数,所以无法直接从vmcore中获取rbp的值,只能想其它办法了。
继续看汇编代码:
/usr/src/debug/kernel-2.6.18/linux-2.6.18.x86_64/kernel/irq/handle.c: 176
0xffffffff800b977c <__do_IRQ+24>:       mov    %rcx,%rbp
0xffffffff800b977f <__do_IRQ+27>:       shl    $0x8,%rbp
这里的rcx应该存放的是irq的编号,也就是178,将rcx左移8位后即得到rbp(shl    $0x8,%rbp),即178*256=rbp=0xb200
0xffffffff803d8380+0xb200=0xffffffff803e3580,该地址即为178号中断对应的描述符的地址了:

点击(此处)折叠或打开

  1. crash> struct irq_desc FFFFFFFF803E3580
  2. struct irq_desc {
  3.   handle_irq = 0,
  4.   chip = 0xffffffff80323c40,
  5.   handler_data = 0x0,
  6.   chip_data = 0x0,
  7.   action = 0xffff81032acdee40,
  8.   status = 65536,
  9.   depth = 0,
  10.   wake_depth = 0,
  11.   irq_count = 78785,
  12.   irqs_unhandled = 0,
  13.   lock = {
  14.     raw_lock = {
  15.       slock = 1
  16.     }
  17.   },
  18.   affinity = {
  19.     bits = {256, 0, 0, 0}
  20.   },
  21.   cpu = 0,
  22.   pending_mask = {
  23.     bits = {32768, 0, 0, 0}
  24.   },
  25.   move_irq = 1,
  26.   dir = 0xffff810328db2380
  27. }
  28. crash> struct irqaction 0xffff81032acdee40
  29. struct irqaction {
  30.   handler = 0xffffffff8827628b,
  31.   flags = 0,
  32.   mask = {
  33.     bits = {0, 0, 0, 0}
  34.   },
  35.   name = 0xffff81032b1c7000 "eth0-rx-3",
  36.   dev_id = 0xffff81032bef56b8,
  37.   next = 0x1,
  38.   irq = 178,
  39.   dir = 0xffff810328db2180

exactly,正是我们需要的,于是找到了描述符,看看其内容,其中
irq_count = 78785,
irq_count用于监测中断是否挂起的计数,不为0表明之前已处理过该中断,说明该中断之前正在被正常处理,突然直接出了问题。

至此,确实无法继续分析了,从故障现象看,内核问题可能性不大,更像是是内存的1bit跳变导致的问题,但是通常的服务器环境中,内存(控制器)硬件应该有ECC校验功能,可以自动纠正1bit跳变的情况才对。
核对了一下出现问题的硬件环境,dmicode命令中可以看到内存硬件确实有ECC校验功能,但是发现CPU cache硬件中没有包含ECC校验功能:
Error Correction Type: None
看了看其它类型的服务器,一些服务器有ECC校验功能:
Error Correction Type: Single-bit ECC

因此,没有其它疑点,只能怀疑是内存(或者说是cache)的1bit跳变硬件故障导致。
但没有进一步证据了,有其它想法欢迎讨论。
阅读(5475) | 评论(2) | 转发(1) |
给主人留下些什么吧!~~

humjb_19832016-05-20 16:27:15

lihuolin008:你好! 我也碰到这个问题,不知道你解决了没?

后续确认是硬件问题,通过内存测试确认的

回复 | 举报

lihuolin0082016-03-16 14:11:24

你好! 我也碰到这个问题,不知道你解决了没?