On Wed, Nov 26, 2014 at 6:34 AM, Dave Jones <da...@redhat.com> wrote:
>
> Woke up to the below trace. Looks like a different issue.
Yeah, apparently the Xen issue was really just a Xen bug.
> NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [trinity-c149:24766]
> RIP: 0010:[<ffffffff8104658c>] [<ffffffff8104658c>]
> kernel_map_pages+0xbc/0x120
Well, this one at least makes some amount of sense. The "Code:" line says it's
1b: 9c pushfq
1c: 5a pop %rdx
1d: fa cli
1e: 0f 20 e0 mov %cr4,%rax
21: 48 89 c1 mov %rax,%rcx
24: 80 e1 7f and $0x7f,%cl
27: 0f 22 e1 mov %rcx,%cr4
2a: 0f 22 e0 mov %rax,%cr4
2d: 52 push %rdx
2e: 9d popfq
2f:* eb cf jmp back <-- trapping instruction
and %rdx is 0x0202 which is actually a valid flags value.
That looks like the code for __native_flush_tlb_global().
Not that interrupt should have been disabled very long.
> Call Trace:
> [<ffffffff81185ebf>] get_page_from_freelist+0x49f/0xaa0
> [<ffffffff811866ee>] __alloc_pages_nodemask+0x22e/0xb60
> [<ffffffff811d093e>] alloc_pages_vma+0xee/0x1b0
> [<ffffffff81194f0e>] shmem_alloc_page+0x6e/0xc0
> [<ffffffff81197880>] shmem_getpage_gfp+0x4d0/0x7e0
> [<ffffffff81197bd2>] shmem_write_begin+0x42/0x70
> [<ffffffff8117c2d4>] generic_perform_write+0xd4/0x1f0
> [<ffffffff8117eac2>] __generic_file_write_iter+0x162/0x350
> [<ffffffff8117ecef>] generic_file_write_iter+0x3f/0xb0
> [<ffffffff811f01b8>] do_iter_readv_writev+0x78/0xc0
> [<ffffffff811f19e8>] do_readv_writev+0xd8/0x2a0
> [<ffffffff811f1c3c>] vfs_writev+0x3c/0x50
> [<ffffffff811f1dac>] SyS_writev+0x5c/0x100
> [<ffffffff817e0249>] tracesys_phase2+0xd4/0xd9
Hmm. Maybe some oom issue, that we spent a long time before this
trying to free pages?
Linus
--
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/
