On Tue, Oct 14, 2014 at 10:25:01AM +0200, Belisko Marek wrote: > Hi Amitkumar, > > On Tue, Oct 14, 2014 at 9:08 AM, Amitkumar Karwar <akarwar@xxxxxxxxxxx> wrote: > > Hi Marek, > > > > > I tried both (slightly modified as we're in 3.9 kernel) but > > > issue is still reproducible. My patch against 3.9 sources: > > > > Thanks a lot for the tests. > > > > > One thing which is not yet still clear to me why kernel console > > > is completely unresponsive when receiving packets in high > > > rates. When use iperf (on client) with -b40m it is OK but when > > > increase to -b100m then console is completely unresponsive until > > > iperf finish. > > > > Does the system recover when "-b100M" iperf is finished? Can we > > run iperf with "-b40M" later? Do you see "dev_alloc_skb failed" > > messages in dmesg when console is unresponsive? > When we get "dev_alloc_skb failed" then interface is dead (cannot > ping ...) so no recovery is possible only system reboot. This symptom was familiar to me, but on sdio.c, which is very different code. I've had a brief look at usb.c and offer the following comments: - a list of six data endpoint urb is allocated in mwifiex_usb_rx_init, because MWIFIEX_RX_DATA_URB is 6, - when data endpoint urb is submitted, a new skb is allocated, in mwifiex_usb_submit_rx_urb, and this is the only source of "dev_alloc_skb failed" message, - in normal situation, when data endpoint urb is complete, skb is either freed or handed up to mwifiex_usb_recv, and the urb is resubmitted, which causes a new skb to be allocated. - if "dev_alloc_skb failed" message appears, one data endpoint urb has been lost and is not re-used, - if six "dev_alloc_skb failed" messages appear, the interface should be dead for data receive only. Amitkumar mentioned this on 9th October; "corresponding URB won't get submitted". I think this should be fixed; dev_alloc_skb should be harmless failure, please retry. I don't see why interface is dead with only one "dev_alloc_skb failed" message. > I don't see dev_alloc_skb failed when console is unresponsive. > > > > > Any other ideas > > > what to change to check? Thanks. > > > > Could you please share dmesg log with dynamic debug enabled (using > > attached script) captured when the problem occurs? > I tried to capture logs but when enable DYNAMIC_DEBUG I cannot > reproduce issue (running test > 30 minutes without allocation > failure). Yes, I've seen similar; turn on debugging, and timing critical bug goes away. Serial console? If so, try turning it off, and logging to dmesg buffer only. -- James Cameron http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
