Return-path: Received: from mail-pb0-f45.google.com ([209.85.160.45]:38266 "EHLO mail-pb0-f45.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751382AbaBDP5V (ORCPT ); Tue, 4 Feb 2014 10:57:21 -0500 Received: by mail-pb0-f45.google.com with SMTP id un15so8562851pbc.18 for ; Tue, 04 Feb 2014 07:57:20 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 4 Feb 2014 21:27:19 +0530 Message-ID: (sfid-20140204_165735_353561_70321D46) Subject: Re: mwifiex and SD8787: TX queue timeout in AP mode From: Avinash Patil To: Andrew Wiley Cc: "linux-wireless@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: Hi Andrew, I think this issue not specific to any interface as such. Do you have following fix in your tree: http://www.spinics.net/lists/linux-wireless/msg112753.html Also can you please try printing adapter->int_status during AP TX data timeout? Thanks, Avinash On Tue, Feb 4, 2014 at 6:47 AM, Andrew Wiley wrote: > On Mon, Feb 3, 2014 at 4:16 PM, Andrew Wiley wrote: >> On Mon, Feb 3, 2014 at 4:02 PM, Andrew Wiley wrote: >>> On Mon, Feb 3, 2014 at 12:47 AM, Avinash Patil wrote: >>>> Does this issue happens with station interface as well? >>> >>> I haven't really made use of station mode much, but I just tried it >>> and it seems stable. The first time I tried to connect, the driver had >>> a command timeout while scanning and the card dropped out, but the >>> second time, it connected and has stayed stable for 30 minutes or so. >>> The network I'm connected to uses WPA2. I'll continue to monitor the >>> box to see if the queue hangs. >>> >> >> A few minutes after I wrote this, the box hung. No kernel errors were >> logged in the serial console - it just stopped responding. >> I'll have to investigate this further. > > There's a consistent but random hang in station mode. I've reproduced > it five times at this point - the serial console hangs and the > heartbeat LED gets stuck on. There aren't any errors leading up to the > hang. > > Here's the last lines of dmesg that printed before the hang: > > ---- > [ 5021.924439] mwifiex_sdio mmc0:0001:1: info: --- Rx: Data packet --- > [ 5021.924576] mwifiex_sdio mmc0:0001:1: data: 471285 BSS(0-0): Data <= kernel > [ 5021.924616] mwifiex_sdio mmc0:0001:1: data: mp_rd_bitmap=0x00000000 > [ 5021.924627] mwifiex_sdio mmc0:0001:1: info: no more rd_port available > [ 5021.924644] mwifiex_sdio mmc0:0001:1: data: tid=0 > [ 5021.924658] mwifiex_sdio mmc0:0001:1: data: dequeuing the packet > ddfb1240 db063cc0 > [ 5021.924674] mwifiex_sdio mmc0:0001:1: data: WMM: Pkt Delay: 0 ms, 0 > ms sent to FW > [ 5021.924685] mwifiex_sdio mmc0:0001:1: data: mp_wr_bitmap=0x0000007f > [ 5021.924697] mwifiex_sdio mmc0:0001:1: data: port=1 > mp_wr_bitmap=0x0000007f -> 0x0000007d > [ 5021.924708] mwifiex_sdio mmc0:0001:1: info: > mwifiex_host_to_card_mp_aggr: Last packet in Tx Queue. > [ 5021.924719] mwifiex_sdio mmc0:0001:1: data: > mwifiex_host_to_card_mp_aggr: send current buffer 1 > [ 5021.979992] mwifiex_sdio mmc0:0001:1: int: sdio_ireg = 0x1 > [ 5021.980014] mwifiex_sdio mmc0:0001:1: info: cmd_sent=0 data_sent=0 > [ 5021.980025] mwifiex_sdio mmc0:0001:1: int: UPLD: rd_bitmap=0x1 > [ 5021.980034] mwifiex_sdio mmc0:0001:1: data: mp_rd_bitmap=0x00000001 > [ 5021.980045] mwifiex_sdio mmc0:0001:1: data: port=0 mp_rd_bitmap=0x00000000 > [ 5021.980055] mwifiex_sdio mmc0:0001:1: info: RX: port=0 rx_len=10 > [ 5021.980068] mwifiex_sdio mmc0:0001:1: info: rx_len = 256 skb->len = 256 > [ 5021.980079] mwifiex_sdio mmc0:0001:1: info: > mwifiex_sdio_card_to_host_mp_aggr: no aggregation for cmd response > [ 5021.980089] mwifiex_sdio mmc0:0001:1: info: RX: port: 0, rx_len: 256 > [ 5021.980137] mwifiex_sdio mmc0:0001:1: info: --- Rx: Event --- > [ 5021.980150] mwifiex_sdio mmc0:0001:1: data: mp_rd_bitmap=0x00000000 > [ 5021.980159] mwifiex_sdio mmc0:0001:1: info: no more rd_port available > [ 5021.980171] mwifiex_sdio mmc0:0001:1: info: EVENT: SLEEP > [ 5021.980183] mwifiex_sdio mmc0:0001:1: info: > mwifiex_host_to_card_mp_aggr: tx aggregation disabled > [ 5021.980194] mwifiex_sdio mmc0:0001:1: data: > mwifiex_host_to_card_mp_aggr: send current buffer 0 > [ 5021.980326] mwifiex_sdio mmc0:0001:1: int: sdio_ireg = 0x1 > [ 5021.980341] mwifiex_sdio mmc0:0001:1: info: cmd_sent=0 data_sent=0 > [ 5021.980351] mwifiex_sdio mmc0:0001:1: int: UPLD: rd_bitmap=0x1 > [ 5021.980361] mwifiex_sdio mmc0:0001:1: data: mp_rd_bitmap=0x00000001 > [ 5021.980371] mwifiex_sdio mmc0:0001:1: data: port=0 mp_rd_bitmap=0x00000000 > [ 5021.980380] mwifiex_sdio mmc0:0001:1: info: RX: port=0 rx_len=16 > [ 5021.980392] mwifiex_sdio mmc0:0001:1: info: rx_len = 256 skb->len = 256 > [ 5021.980403] mwifiex_sdio mmc0:0001:1: info: > mwifiex_sdio_card_to_host_mp_aggr: no aggregation for cmd response > [ 5021.980413] mwifiex_sdio mmc0:0001:1: info: RX: port: 0, rx_len: 256 > [ 5021.980456] mwifiex_sdio mmc0:0001:1: info: --- Rx: Cmd Response --- > [ 5021.980471] mwifiex_sdio mmc0:0001:1: data: mp_rd_bitmap=0x00000000 > [ 5021.980480] mwifiex_sdio mmc0:0001:1: info: no more rd_port available > ---- > > Unfortunately, this is from `dmesg -w` and not directly from the > serial console - I think I'll have to recompile the kernel again to > get these debug messages to show up on the serial console, and I'm not > sure what will happen when the message rate exceeds the speed of the > serial connection. > > Is this likely a separate issue? Should I see if I can get GDB set up > over JTAG and dump the message buffers after the lockup?