On 04/17, Peter Chiang wrote: > > It is a speculation where the panic was. > > [38261.652100] Call trace: > [38261.654616] [<ffffffc000aa6fe0>] mm_update_next_owner+0x190/0x238 > [38261.660766] [<ffffffc000aa728c>] do_exit+0x204/0x924 > [38261.665790] [<ffffffc000aa7a1c>] do_group_exit+0x40/0xcc > [38261.671169] [<ffffffc000ab59cc>] get_signal_to_deliver+0x218/0x57c > [38261.677409] [<ffffffc000a87e6c>] do_signal+0x534/0x550 > [38261.682608] [<ffffffc000a88070>] do_notify_resume+0x20/0x58
Could you show the full dmesg? Could you look into asm/objdump/addr2line to figure out what this mm_update_next_owner+0x190 means? Is it reproducable? Hmm. I seem to see a bug in this function, it can be fulled by use_mm, but I am not sure this can explain the problem. I'll send a patch. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
