Return-path: Received: from mail-la0-f41.google.com ([209.85.215.41]:36171 "EHLO mail-la0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751177AbbEQTWq (ORCPT ); Sun, 17 May 2015 15:22:46 -0400 Received: by lagv1 with SMTP id v1so190579703lag.3 for ; Sun, 17 May 2015 12:22:45 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <55575AC8.2060301@lwfinger.net> <5557844B.4040108@lwfinger.net> <55586D8D.7040407@gmail.com> Date: Sun, 17 May 2015 22:22:45 +0300 Message-ID: (sfid-20150517_212249_719855_07368057) Subject: Re: kernel page fault in r8712u From: Haggai Eran To: Arend van Spriel Cc: Larry Finger , Florian Schilhabel , linux-wireless@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: I added some debugging prints, trying to see more details about the packet that fails the r8712_validate_recv_frame. I noticed I'm getting many packets where recv_decache returns _FAIL. However, the last two packets before the crash fail for different reasons. The first has the ver field set to 3 (instead of zero). The second (the one that get's freed and cause the crash apparently) has an unknown type (12). If I'm not mistaken, 12 = WIFI_CTRL_TYPE | WIFI_DATA_TYPE. Is that possible? It could be that the packet headers are garbled though. Haggai On 17 May 2015 at 20:20, Haggai Eran wrote: > On 17 May 2015 at 13:29, Arend van Spriel wrote: >> On 17-05-15 06:25, Haggai Eran wrote: >>> >>> On 16 May 2015 at 20:54, Larry Finger wrote: >>>> >>>> Another location needed from gdb is "l *recv_func+0x8c". >>> >>> >>> Here it is: >>> (gdb) l *recv_func+0x8c >>> 0x17094 is in recv_func (drivers/staging/rtl8712/rtl8712_recv.c:1004). >>> 999 r8712_free_recvframe(orig_prframe, >>> pfree_recv_queue); >>> 1000 goto _exit_recv_func; >>> 1001 } >>> 1002 _exit_recv_func: >>> 1003 return retval; >>> 1004 } >>> 1005 >>> 1006 static int recvbuf2recvframe(struct _adapter *padapter, struct >>> sk_buff *pskb) >>> 1007 { >>> 1008 u8 *pbuf, shift_sz = 0; >>> >>> I don't think this means the relevant call is the one at line 999. I >>> think it is an earlier call, after r8712_validate_recv_frame. Here's >>> the disassembly: >> >> >> can you provide the address of recv_func as well to determine the exact >> location in assembly. > > Yes, it is in offset 0x17008 in the module: >> 00017008 : > > Regards, > Haggai > >> >>> /* check the frame crtl field and decache */ >>> retval = r8712_validate_recv_frame(padapter, prframe); >>> 17070: e1a00004 mov r0, r4 >>> 17074: e1a01005 mov r1, r5 >>> 17078: ebfffffe bl 17bc0 >>> if (retval != _SUCCESS) { >>> 1707c: e3500001 cmp r0, #1 >>> r8712_free_recvframe(orig_prframe, >>> pfree_recv_queue); >>> goto _exit_recv_func; >>> } >>> } >>> /* check the frame crtl field and decache */ >>> retval = r8712_validate_recv_frame(padapter, prframe); >>> 17080: e1a06000 mov r6, r0 >>> if (retval != _SUCCESS) { >>> 17084: 0a000005 beq 170a0 >>> /* free this recv_frame */ >>> r8712_free_recvframe(orig_prframe, pfree_recv_queue); >>> 17088: e1a00005 mov r0, r5 >>> 1708c: e1a01007 mov r1, r7 >>> 17090: ebfffffe bl 166e8 >>> r8712_free_recvframe(orig_prframe, pfree_recv_queue); >>> goto _exit_recv_func; >>> } >>> _exit_recv_func: >>> return retval; >>> } >>> 17094: e1a00006 mov r0, r6