linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Max Filippov <jcmvbkbc@gmail.com>
To: Christian Lamparter <chunkeey@web.de>
Cc: "linux-wireless" <linux-wireless@vger.kernel.org>,
	Larry Finger <Larry.Finger@lwfinger.net>
Subject: Re: [WIP] p54: deal with allocation failures in rx path
Date: Sun, 5 Jul 2009 04:56:59 +0400	[thread overview]
Message-ID: <200907050457.00689.jcmvbkbc@gmail.com> (raw)
In-Reply-To: <200907040053.05654.chunkeey@web.de>

> This patch tries to address a long standing issue: 
> how to survive serve memory starvation situations,
> without losing the device due to missing transfer-buffers.
> 
> And with a flick of __GFP_NOWARN, we're able to handle ?all? memory
> allocation failures on the rx-side during operation without much fuss.
> 
> However, there is still an issue within the xmit-part.
> This is likely due to p54's demand for a large free headroom for
> every outgoing frame:
> 
>  + transport header (differs from device to device)
>       -> 16 bytes transport header (USB 1st gen)
>       -> 8 bytes for (USB 2nd gen)
>       -> 0 bytes for spi & pci
>  + 12 bytes for p54_hdr
>  + 44 bytes for p54_tx_data
>  + up to 3 bytes for alignment
> (+ 802.11 header as well? )
> 
> and this is where ieee80211_skb_resize comes into the play...
> which will try to _relocate_ (alloc new, copy, free old) frame data,
> as the headroom is most of the time simply not enough.
> =>
>  Call Trace: (from Larry - Bug #13319 )
>  [<ffffffff80292a7b>] __alloc_pages_internal+0x43d/0x45e
>  [<ffffffff802b1f1f>] alloc_pages_current+0xbe/0xc6
>  [<ffffffff802b6362>] new_slab+0xcf/0x28b
>  [<ffffffff802b4d1f>] ? unfreeze_slab+0x4c/0xbd
>  [<ffffffff802b672e>] __slab_alloc+0x210/0x44c
>  [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
>  [<ffffffff803e7bee>] ? pskb_expand_head+0x52/0x166
>  [<ffffffff802b7e60>] __kmalloc+0x119/0x194
>  [<ffffffff803e7bee>] pskb_expand_head+0x52/0x166
>  [<ffffffffa02913d6>] ieee80211_skb_resize+0x91/0xc7 [mac80211]
>  [<ffffffffa0291c0f>] ieee80211_master_start_xmit+0x298/0x319 [mac80211]
>  [<ffffffff803ef72a>] dev_hard_start_xmit+0x229/0x2a8
> (sl*b debug option will help to bloat even more.)
> 
> So?! how to prevent ieee80211_skb_resize from raping
> the bits of memory left?
> 
> the simplest answer is probably this one:
> https://dev.openwrt.org/changeset/15761
> --
> 
> back to rx  failures.
> the attached code below was only usb was tested so far!
> you have been warned!
> 
> regards,
> 	chr
> 
> btw: max what do you think about the p54spi changes, are they total ****?

Christian, I'm trying to test it, but it seems that many things have changed since 2.6.28.
Right now I see this:

[  416.738586] Freeing init memory: 140K                                                                                     
[  417.208801] cx3110x spi2.0: firmware: requesting 3826.arm                                                                 
[  417.272094] hub 1-0:1.0: hub_suspend                                                                                      
[  417.272155] usb usb1: bus auto-suspend                                                                                    
[  417.295501] phy0: p54 detected a LM20 firmware                                                                            
[  417.298034] p54: rx_mtu reduced from 3240 to 2376                                                                         
[  417.300598] phy0: FW rev 2.13.0.0.a.22.8 - Softmac protocol 5.6                                                           
[  417.303558] phy0: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:YES                                                   
[  417.306732] cx3110x spi2.0: firmware: requesting 3826.eeprom                                                              
[  417.385742] firmware spi2.0: firmware_loading_store: vmap() failed                                                        
[  417.391540] cx3110x spi2.0: loading default eeprom...                                                                     
[  417.395568] phy0: hwaddr 00:02:ee:c0:ff:ee, MAC:isl3820 RF:Longbow                                                        
[  417.468841] phy0: Selected rate control algorithm 'minstrel'                                                              
[  417.473693] cx3110x spi2.0: is registered as 'phy0'                                                                       
[  419.150909] g_ether gadget: notify connect false                                                                          
[  419.182891] g_ether gadget: notify speed 425984000                                                                        
[  420.409210] usb0: eth_open                                                                                                
[  420.409240] usb0: eth_start                                                                                               
[  420.409423] g_ether gadget: ecm_open                                                                                      
[  420.409454] g_ether gadget: notify connect true                                                                           
[  420.430908] g_ether gadget: notify speed 425984000
[  421.186340] phy0: device now idle
[  421.200958] skb_over_panic: text:bf000498 len:2 put:2 head:c793a200 data:c793a220 tail:0xc793a222 end:0xc793a220 dev:<NULL>
[  421.211669] kernel BUG at net/core/skbuff.c:127!
[  421.217407] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[  421.223571] pgd = c0004000
[  421.229797] [00000000] *pgd=00000000
[  421.236236] Internal error: Oops: 817 [#1]
[  421.242736] Modules linked in: p54spi
[  421.249420] CPU: 0    Not tainted  (2.6.31-rc1-omap1-wl #4)
[  421.256378] PC is at __bug+0x1c/0x28
[  421.263458] LR is at __bug+0x18/0x28
[  421.270538] pc : [<c002f828>]    lr : [<c002f824>]    psr: 60000113
[  421.270568] sp : c798ff20  ip : 00000000  fp : 00000000
[  421.284851] r10: 00000000  r9 : 00000000  r8 : c7976b34
[  421.291870] r7 : c793a220  r6 : c793a222  r5 : c793a220  r4 : c793a200
[  421.298980] r3 : 00000000  r2 : c033cb84  r1 : 000045b2  r0 : 0000003a
[  421.306091] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[  421.313323] Control: 00c5387d  Table: 87fe0000  DAC: 00000017
[  421.320526] Process phy0 (pid: 426, stack limit = 0xc798e268)
[  421.327697] Stack: (0xc798ff20 to 0xc7990000)
[  421.334747] ff20: 00000002 c01dc03c c793a200 c793a220 c793a222 c793a220 c02fba60 00000000
[  421.342346] ff40: c798ff40 c784abc0 c793a220 bf000498 c784abc0 c01dd1a8 00000058 c7976940
[  421.349975] ff60: c798ff6e bf000498 c798e000 80000058 c7976afc c7976940 50000000 c7976b0c
[  421.357574] ff80: 00000000 bf0008ec c796fd20 10000000 c0060510 bf000808 c796fd20 c798e000
[  421.365173] ffa0: c0060510 c0060650 c798ffd4 00000000 c78cc9a0 c00636ac c798ffb8 c798ffb8
[  421.372558] ffc0: c798ffd4 c7951d98 c796fd20 c0063440 00000000 00000000 c798ffd8 c798ffd8
[  421.379730] ffe0: 00000000 00000000 00000000 00000000 00000000 c002cca8 53384842 4e86725f
[  421.386993] Code: e1a01000 e59f000c eb0088c3 e3a03000 (e5833000)
[  421.394104] ---[ end trace 75ac12f5b28efc30 ]---

Looks like something's wrong with firmware loading. 
I hope to fix it tomorrow and see how your changes work.

Thanks.
-- Max

  parent reply	other threads:[~2009-07-05  0:57 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-03 22:53 [WIP] p54: deal with allocation failures in rx path Christian Lamparter
2009-07-04  1:09 ` Larry Finger
2009-07-04  2:16 ` Larry Finger
2009-07-04 10:11   ` Christian Lamparter
2009-07-04 16:40     ` Larry Finger
2009-07-04 17:28       ` Christian Lamparter
2009-07-04 19:56         ` Larry Finger
2009-07-04 21:14           ` Larry Finger
2009-07-05 13:59             ` Christian Lamparter
2009-07-05 17:49               ` Larry Finger
2009-07-05 22:05                 ` Christian Lamparter
2009-07-06  1:36                   ` Larry Finger
2009-07-06 13:16                     ` Christian Lamparter
2009-07-04  7:52 ` Johannes Berg
2009-07-05  0:56 ` Max Filippov [this message]
2009-07-05 14:00   ` Christian Lamparter
2009-07-05 19:16     ` Max Filippov
2009-07-05 22:46       ` Max Filippov
2009-07-06 13:11 ` Max Filippov
2009-07-06 14:00   ` Christian Lamparter
2009-07-06 14:18     ` Max Filippov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200907050457.00689.jcmvbkbc@gmail.com \
    --to=jcmvbkbc@gmail.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=chunkeey@web.de \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).