On Thu, Jan 07, 2016 at 09:58:14AM +0100, Holger Schurig wrote: > This oops with sock_recvmsg() inside it now happened 3 times, just not > at my test box, only at one very remote from me. That's also the reason > why the log is truncated, the people that grabbed it from Windows with > Putty over the serial line just did give this to me ... :-(
It's a little incomplete, but luckily we have some useful information buried in it. > BTW, are several places with "???" below. Is this just a "grabbing from > Windows" artifact? Or an indication that the processor/memory of the > system got completely insane? No idea, sorry. ... > [<c00171c4>] (do_page_fault) from [<c000934c>] (do_PrefetchAbort+0x3c/0xa0) > r10:c0037790 r9:00000001 r8:00000001 r7:ed9a9bf8 r6:fffffffe r5:c055fbc4 > r4:00000007 > [<c0009310>] (do_PrefetchAbort) from [<c001354c>] (__pabt_svc+0x4c/0x80) > Exception stack(0xed9a9bf8 to 0xed9a9c40) > 9be0:?????????????????????????????????????????????????????? ebaa3d18 00000001 > 9c00: 00000001 00000304 ee1c2c04 fffffff3 00000001 00000304 00000001 00000001 > 9c20: c0037790 ed9a9c74 ffffffff ed9a9c48 c004febc fffffffe 800100b3 ffffffff These are the registers - r0 to pc, cpsr and "orig_r0". The PC value triggering the prefetch abort was 0xfffffffe, and the link register was 0xc004febc - this should be the instruction after the call. To do any diagnosis, I'd need the disassembly around the link register - it may be best if you can send me the vmlinux file itself by private mail in case I need to reference other functions too. I've left the remainder of the trace in place - please retain it when you reply with the disassembly so I can refer directly to it in my next reply without having to find the previous email. Thanks. > r7:ed9a9c2c r6:ffffffff r5:800100b3 r4:fffffffe > [<c004fe68>] (__wake_up_common) from [<c00504ac>] > (__wake_up_sync_key+0x4c/0x60) > r10:00000000 r9:00000010 r8:00000304 r7:00000001 r6:00000001 r5:a0010013 > r4:ee1c2c00 r3:00000001 > [<c0050460>] (__wake_up_sync_key) from [<c03cf9d0>] > (unix_write_space+0x60/0x90) > r8:ed9a9df4 r7:eb9decc0 r6:ed95d5e4 r5:ed95f02c r4:ed95ef80 > [<c03cf970>] (unix_write_space) from [<c0347674>] (sock_wfree+0x4c/0x84) > r4:ed95ef80 r3:c03cf970 > [<c0347628>] (sock_wfree) from [<c03cf2b8>] (unix_destruct_scm+0x6c/0x74) > r5:00000000 r4:eb9decc0 > [<c03cf24c>] (unix_destruct_scm) from [<c0348768>] > (skb_release_head_state+0x70/0xb0) > r4:eb9decc0 > [<c03486f8>] (skb_release_head_state) from [<c034b280>] > (skb_release_all+0x14/0x2c) > r4:eb9decc0 r3:00000001 > [<c034b26c>] (skb_release_all) from [<c034b2ac>] (__kfree_skb+0x14/0x94) > r4:eb9decc0 r3:00000001 > [<c034b298>] (__kfree_skb) from [<c034b610>] (consume_skb+0x58/0x5c) > r4:ed95d400 r3:00000001 > [<c034b5b8>] (consume_skb) from [<c03d050c>] > (unix_stream_read_generic+0x5ec/0x750) > [<c03cff20>] (unix_stream_read_generic) from [<c03d0754>] > (unix_stream_recvmsg+0x50/0x5c) > r10:ecc13800 r9:ed9a9e88 r8:bee12988 r7:00000040 r6:ecc13800 r5:ed9a9f4c > r4:00001000 > [<c03d0704>] (unix_stream_recvmsg) from [<c0341250>] (sock_recvmsg+0x18/0x1c) > r7:bee1296c r6:00000040 r5:00000000 r4:ed9a9f4c > [<c0341238>] (sock_recvmsg) from [<c0342fa0>] (___sys_recvmsg+0x98/0x170) > [<c0342f08>] (___sys_recvmsg) from [<c0343d34>] (__sys_recvmsg+0x44/0x68) > r10:00000000 r9:ed9a8000 r8:c000f1e4 r7:00000129 r6:bee1296c r5:00000000 > r4:ecc13800 > [<c0343cf0>] (__sys_recvmsg) from [<c0343d68>] (SyS_recvmsg+0x10/0x14) > r6:b6f7df10 r5:81196c08 r4:bee12988 > [<c0343d58>] (SyS_recvmsg) from [<c000f020>] (ret_fast_syscall+0x0/0x3c) -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
