[Xenomai-help] Kernel panic: not syncing - part 2

[Xenomai-help] Kernel panic: not syncing - part 2

[Petr Cervenka]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]

Hello again,
I have though, that all my troubles with this kernel panic (see https://mail.gna.org/public/xenomai-help/2008-07/msg00054.html) are over, but suddenly it reappeared.
The full log is in attachment. I used snapshot of screen, OCR program and manual correction, so expect possible errors in log.
I haven't seen the error for months, I was believed that it was caused the combination of other two problems (hopefully already solved or evaded). But this kernel panic emerged  during the weekend test, when we tested usability of a new motherboard for our purposes.
It's perhaps not critical for me, but if you have any advices or questions, I'm listening.
Thanks
Petr


[-- Attachment #2: kernel_panic.txt --]
[-- Type: text/plain, Size: 4208 bytes --]

06.12.08 07:35:13> * Reloading system log daemon... 
07.12.08 07:35:07> * Reloading system log daemon... 
07.12.08 16:34:47> [187400.106786] BUG: unable to handle kernel paging request at 0000000041bcadf8 
[187400.106899] IP: [<ffffffff802101b6> profile_pc+0x46/0x80 
[187400.111866] PGD 6e9a0067 PUD 6e14d067 PND 0 
[187400.110866] Oops 0000 [1] PREEMPT SMP 
[187400.110866] CPU 0 
[187400.110866] Modules linked in: ppdev e1000 r8169 rt_e1000 rt_r8169 rtpacket container rtnet ac video output sbs sbshc battery af_packet parport_pc ip parpor 
t k8temp button ipv6 evdev ext3 jbd mbache usbhid hid sg sd_mod ata_generic ahci libata scsi_mod dock forcedeth amd74xx ide_core ehci_hcd ohci_hcd usbcore fan 
thermal_sys fuse [last unloaded: e1000] 
[187400.110866] Pid: 309, comm: gatekeepper/0 Not tainted 2.6.26.3—adeos #6 
[187400.110666] RIP: 0010:[<ffffffff802101b6>] [<ffffffff802101b6>] profile_pc+0x46/0x80 
[187400.110866] RSP 0018:ffff81006dfabb98 EFLAGS: 00010202
[187400.110866] RAX; 0000000000000001 RBX: ffff810001011740 RCX: 0000000041bcadf8
[187400.110866] RDX: ffff810080991000 RSI: 0000000000000000 RDI: ffffffff8049c44a
[187400.110866] RBP: ffffffff8049c44a R08: 0000000000000001 R09: 0000000000000010
[187400.110866] R10: 0000000000000001 R11: ffffffff802223aO R12: 0000a1b9a8528911
[187400.110866] R13: ffff810001013360 R14: 0000000000000001 R15: 7fffffffffffffff
[187400.110866] FS:  000000004lbcb950(0000) GS:ffffffff805fc000(0000) kn1GS:0000000000000000
[187400.110866] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
[187400.110866] CR2: 0000000041bcadf8 CR3: 000000006e354000 CR4: 00000000000006e0
[187400.110866] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[187400.110866] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[187400.110666] Process gatekeeper/0 (pid: 309. threadinfo ffff81006dfaa000, task ffff81006fb763e0)
[187400.110866] Stack: ffff81006fb763e0 ffff810001011740 0000000000000001 ffffffff8023a5ae
[187400.110866]  ffff810001013360 1f11110001013460 f111810001011740 111f11f180250773
[187400.110866]  ffff810001013460 ffffffff80258700 ffff810001O133b8 ffffffff80251154
[187400.110866] Call Trace: 
[187400.110866]  [<ffffffff8023a5ae>] ? profile_tick+0x5e/0xa0 
[187400.110866]  [<ffffffff80258773>] ? tick_sched_timer+0x73/0xe0
[187400.110866]  [<ffffffff80258700>] ? tick_sched_timer+0x0/0xe0
[187400.110866]  [<ffffffff80251154>] ? __run_hrtimer+0x94/0xb0
[187400.110866]  [<ffffffff80251e28>] ? hrtimer_interrupt+0x108/0x180
[187400.110866]  [<ffffffff8021d6ac>] ? smp_apic_timer_interrupt+0x6c/0xb0 
[187400.110066]  [<ffffffff80271b57>] ? __ipipe_sync_stage+0x317/Ox31c 
[187400.110666]  [<ffffffff8021d640>] ? smp_apic_timer_interrupt+0x0/0xb0
[187400.110066]  [<ffffffff80271b5c>] ? __xirq_end+0x0/0X86 
[187400.110666]  [<ffffffff8021d640>] ? smp_apic_interrupt+0x0/0xb0 
[187400.110666]  [<ffffffff8022e775>] ? update_curr_rt+0xb5/0x2d0 
[187400.110866]  [<ffffffff80271fae>] ? __ipipe_unstall_root+0x5e/0x60 
[187400.110866]  [<ffffffff8049c97b>] ? _spin_unlocK_irq+0Xb/0X40 
[187400.110866]  [<ffffffff8022d08b>] ? finish_task_switch+0x3b/0xC0 
[187400.110866]  [<ffffffff8049a6b5>] ? thread_return+0x7a/0x5c5
[187400.110866]  [<ffffffff80283ea4>] ? gatekeeper_tread+0x104/0x240
[187400.110866]  [<ffffffff8022d910>] ? default_wake_function+0x0/0x10
[187400.110866]  [<ffffffff80283da0>] ? gatekeeper_thread+0x0/0x240
[187400.110866]  [<ffffffff8024e09b>] ? kthread+0x4b/0x80
[187400.110866]  [<ffffffff8020d238>] ? child_rip+0xa/Ox12
[187400.110866]  [<ffffffff8024e050>] ? kthread+0x0/0x80
[187400.110866]  [<ffffffff8020d22e>] ? child_rip+0x0/0x12
[187400.110866]
[187400.110866] Code: 80 00 00 00 74 12 48 89 e8 48 8b 5c 24 08 48 8b 6c 24 10 48 83 c4 18 c3 48 89 ef e8 65 cc 04 00 85 cO 74 e2 48 8b 8b 98 00 00 00 <48> 8b 1
1 40 89 d0 48 c1 e8 16 48 85 c0 75 1b 48 8b 51 08 48 89 
[107400.110866] RIP  [<ffffffff802101b6>] profile_pc+0x46/0x80 
[107400.110866]  RSP <ffff81006dfabb98> 
[187400.110866] CR2: 0000000041bcadf8 
[187400.110866] ---[ end trace e759c864f959fb15 ]--- 
[187400.110866] Kernel panic - not syncing: Aiee, killing interrupt handler 

Re: [Xenomai-help] Kernel panic: not syncing - part 2

[Philippe Gerum]

Petr Cervenka wrote:
> Hello again,
> I have though, that all my troubles with this kernel panic (see https://mail.gna.org/public/xenomai-help/2008-07/msg00054.html) are over, but suddenly it reappeared.
> The full log is in attachment. I used snapshot of screen, OCR program and manual correction, so expect possible errors in log.
> I haven't seen the error for months, I was believed that it was caused the combination of other two problems (hopefully already solved or evaded). But this kernel panic emerged  during the weekend test, when we tested usability of a new motherboard for our purposes.
> It's perhaps not critical for me, but if you have any advices or questions, I'm listening.

Due to the interrupt deferral the I-pipe enforces, it may well happen that we
log and postpone a timer IRQ while the root stage is stalled during a task
switch, which gets eventually played right after the context switch has taken
place, after a different memory context for the next task is reinstated. The
profiler code then tries to dereference a memory address obtained from the IRQ
stack frame that does not exist in the new context. Too bad.

Ok, we need to think about this.

> Thanks
> Petr
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help


-- 
Philippe.