Re: mwifiex_usb_submit_rx_urb: dev_alloc_skb failed when conected to 5GHz

[James Cameron <quozl@laptop.org>]

On Tue, Oct 14, 2014 at 12:48:07PM +0200, Belisko Marek wrote:
> Dear James Cameron,
> 
> On Tue, Oct 14, 2014 at 12:20 PM, James Cameron <quozl@laptop.org> wrote:
> > 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@marvell.com> 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.
> Maybe my description wasn't  not correct. I see 6 "dev_alloc_skb
> failed" messages and then interface is dead
> as you wrote.

Thanks.  That is what I expected.

> >> 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.
> When turning off serial console how then I get kernel messages from
> dmesg buffer?

I use three techniques depending on how usable the system is afterwards:

0.  capture kernel messages to disk, using rsyslog or other user space
assistance; often there is enough information saved before the system
is unresponsive,

1.  type dmesg at a console shell prompt,

2.  watchdog trigger system reset, and in firmware locate the dmesg
buffer structures in memory, and dump them to serial.

http://lists.laptop.org/pipermail/devel/2012-January/034253.html

-- 
James Cameron
http://quozl.linux.org.au/