Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 4 marca 2011 00:49 użytkownik chris at martin.cc <chris at martin.cc> napisał:
> 2011/3/3 Rafał Miłecki <zajec5 at gmail.com>:
>> W dniu 3 marca 2011 08:58 użytkownik Rafał Miłecki <zajec5 at gmail.com> napisał:
>>> 2011/3/3 chris at martin.cc <chris at martin.cc>:
>>>> root at OpenWrt:/etc/config# wifi up
>>>> Error for wireless request "Set Power Management" (8B2C) :
>>>>    SET failed on device wlan0 ; Operation not supported.
>>>> compat-wireless-2011-02-25/drivers/net/wireless/b43/main.c:2262
>>>> kzalloc 332 bytes
>>>> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>>>> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 96 bytes
>>>> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 96 bytes
>>>> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 96 bytes
>>>> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 96 bytes
>>>> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 96 bytes
>>>> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 96 bytes
>>>> b43-phy0 ERROR: PHY transmission error
>>>> b43-phy0 ERROR: PHY transmission error
>>>> b43-phy0 ERROR: PHY transmission error
>>>> b43-phy0 ERROR: PHY transmission error
>>>> b43-phy0 ERROR: PHY transmission error
>>>
>>> This gave me some hint, may be very important. I would like you to
>>> test two patches (together, both at same time), TX header related.
>>> Unfortunately second one doesn't exist yet and I'm leaving for my
>>> studies class soon. I'll send you patches later today.
>>
>> Please, apply that two patches. First one:
>> http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=3311abbbbff1719bbbc8208761e4a75f095f383c
>> Second one is the one I attached.
>>
>> You can revert your switching to PIO and debugging messages if you
>> wish. That doesn't matter.
>>
>>
>> My idea of what is happening:
>> 1) We try to use newer firmware which does not forgive us broken TX
>> header anymore
>> 2) Radio does not transmit, or transmits rubbishes
>> 3) mac80211 detects failure of transmitting and hits some allocation
>> loop, memory leak
>>
>> If that patches help, it means we satisfied newer firmware and TX
>> transmission goes fine. However there still probably is some alloc bug
>> in mac80211 that was exposed by b43.
>
> Rafał
>
> Thanks for taking the time to make the patches.
>
> Unfortunatly, while fixing the TX error, it didn't solve the OoM problem
>
> The first patch was already included in the OpenWrt compat-wireless package
> I applied the second, and the results are below
> I also print the kcalloc() and other *alloc*() I can find.
> I also tested in STA mode, as this was the mode that showed the TX errors
>
> The is a large number of allocated skb's, but this may be caused by
> the traffic in the air here.
> It repeats about 500 times, before running out of memory,
> This would account for 1-2M of memory - depending on allocation. And I
> have > 12M of free memory
>
> root at OpenWrt:/etc/config# wifi up
> Error for wireless request "Set Power Management" (8B2C) :
>    SET failed on device wlan0 ; Operation not supported.
> compat-wireless-2011-02-25/drivers/net/wireless/b43/main.c:2262
> kzalloc 332 bytes
> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:827 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:836 kcalloc
> 256 * 12 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:870 kcalloc
> 128 * 12 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:404 dma_alloc_coherent
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:827 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:836 kcalloc
> 256 * 12 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:870 kcalloc
> 128 * 12 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:404 dma_alloc_coherent
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:827 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:836 kcalloc
> 256 * 12 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:870 kcalloc
> 128 * 12 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:404 dma_alloc_coherent
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:827 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:836 kcalloc
> 256 * 12 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:870 kcalloc
> 128 * 12 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:404 dma_alloc_coherent
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:827 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:836 kcalloc
> 256 * 12 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:870 kcalloc
> 128 * 12 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:404 dma_alloc_coherent
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:827 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:836 kcalloc
> 64 * 12 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:404 dma_alloc_coherent
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:586
> __dev_alloc_skb 2352 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:586
> __dev_alloc_skb 2352 bytes
>
>  ** Repeate 500 times **
>
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:586
> __dev_alloc_skb 2352 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:586
> __dev_alloc_skb 2352 bytes
> uci: page allocation failure. order:0, mode:0x20
> Call Trace:
> [<80009120>] dump_stack+0x8/0x34
> [<8006412c>] __alloc_pages_nodemask+0x514/0x570
> [<8008d214>] cache_alloc_refill+0x280/0x740
> [<8008d880>] kmem_cache_alloc+0x84/0xf4
> [<81a22220>] 0x81a22220

Is this sane to assume that skb allocated in dma.c:586 (:585
unmodified) is leaking?

I checked code path, it is following:
dma_rx
  setup_rx_descbuffer
  b43_rx

Our b43_rx seems to be safe: we check info from rxhdr and use "goto
drop;" in case of failure (which nicely frees skb) OR we call
ieee80211_rx_ni and return. Hoping mac80211 will handle that packet
and free skb.

So my only idea is that mac80211 does not free skb in ieee80211_rx_ni.
That functions is just a simple inline:
static inline void ieee80211_rx_ni(struct ieee80211_hw *hw,
				   struct sk_buff *skb)
{
	local_bh_disable();
	ieee80211_rx(hw, skb);
	local_bh_enable();
}

Is that correct path I follow? Should we investigate ieee80211_rx?

-- 
Rafał