Switching to 4.174.64.19 firmware for G-PHY cards?

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

Currently we tell ppl to use 4.150.10.5 for G-PHY and 4.174.64.19 for
LP-PHY on our wiki page.

Firmware files for G-PHY differ a little between there two versions,
but did we actually get any problems reports?

Can we drop 4.150.10.5 description?

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 7 grudnia 2010 13:21 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> Currently we tell ppl to use 4.150.10.5 for G-PHY and 4.174.64.19 for
> LP-PHY on our wiki page.
>
> Firmware files for G-PHY differ a little between there two versions,
> but did we actually get any problems reports?
>
> Can we drop 4.150.10.5 description?

openSUSE 11.3 seems to download 4.174.64.19 only with it's script and
I didn't heard about any reports. One more point for dropping
4.150.10.5?

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[Larry Finger]

On 12/07/2010 06:28 AM, Rafa? Mi?ecki wrote:
> W dniu 7 grudnia 2010 13:21 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>> Currently we tell ppl to use 4.150.10.5 for G-PHY and 4.174.64.19 for
>> LP-PHY on our wiki page.
>>
>> Firmware files for G-PHY differ a little between there two versions,
>> but did we actually get any problems reports?
>>
>> Can we drop 4.150.10.5 description?
> 
> openSUSE 11.3 seems to download 4.174.64.19 only with it's script and
> I didn't heard about any reports. One more point for dropping
> 4.150.10.5?

I pushed the patch to change openSUSE's script early in the beta testing for
that release. I have heard no complaints either. I agree that 4.150.10.5 should
be dropped.

Larry

Switching to 4.174.64.19 firmware for G-PHY cards?

[Hauke Mehrtens]

On 12/07/2010 04:32 PM, Larry Finger wrote:
> On 12/07/2010 06:28 AM, Rafa? Mi?ecki wrote:
>> W dniu 7 grudnia 2010 13:21 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>>> Currently we tell ppl to use 4.150.10.5 for G-PHY and 4.174.64.19 for
>>> LP-PHY on our wiki page.
>>>
>>> Firmware files for G-PHY differ a little between there two versions,
>>> but did we actually get any problems reports?
>>>
>>> Can we drop 4.150.10.5 description?
>>
>> openSUSE 11.3 seems to download 4.174.64.19 only with it's script and
>> I didn't heard about any reports. One more point for dropping
>> 4.150.10.5?
> 
> I pushed the patch to change openSUSE's script early in the beta testing for
> that release. I have heard no complaints either. I agree that 4.150.10.5 should
> be dropped.

We had serious issues with firmware version 4.174.64.19 in OpenWrt and
switched back to the old on as the default option. This issue afftected
mostly LP-PHY devices.

See the Bug report: https://dev.openwrt.org/ticket/6907 This was with
kernel 2.6.32 and compat-wireless from  round about March to May 2010.
Stable means the old firmware version and experimental the new one in
the bug report.

Hauke

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 7 grudnia 2010 20:21 u?ytkownik Hauke Mehrtens
<hauke@hauke-m.de> napisa?:
> On 12/07/2010 04:32 PM, Larry Finger wrote:
>> On 12/07/2010 06:28 AM, Rafa? Mi?ecki wrote:
>>> W dniu 7 grudnia 2010 13:21 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>>>> Currently we tell ppl to use 4.150.10.5 for G-PHY and 4.174.64.19 for
>>>> LP-PHY on our wiki page.
>>>>
>>>> Firmware files for G-PHY differ a little between there two versions,
>>>> but did we actually get any problems reports?
>>>>
>>>> Can we drop 4.150.10.5 description?
>>>
>>> openSUSE 11.3 seems to download 4.174.64.19 only with it's script and
>>> I didn't heard about any reports. One more point for dropping
>>> 4.150.10.5?
>>
>> I pushed the patch to change openSUSE's script early in the beta testing for
>> that release. I have heard no complaints either. I agree that 4.150.10.5 should
>> be dropped.

Sorry for responding so late, that bug reports scared me at first
look, I switched to sth else to forgot that case.


> We had serious issues with firmware version 4.174.64.19 in OpenWrt and
> switched back to the old on as the default option. This issue afftected
> mostly LP-PHY devices.
>
> See the Bug report: https://dev.openwrt.org/ticket/6907 This was with
> kernel 2.6.32 and compat-wireless from ?round about March to May 2010.
> Stable means the old firmware version and experimental the new one in
> the bug report.

OK, I can see there are 2 bug reports:
https://dev.openwrt.org/ticket/7117
https://dev.openwrt.org/ticket/6907

First one #7117 is about some memory leak and "page allocation
failure" as a result. It really should have nothing to do with
firmware, I guess we just had some memory leak in b43.

Second one #6907 is much worse...

1) At beginning it's about hanging router, it seems to be also (the
same?) memory leak. Probably scanning triggers it. Out of memory leads
to killing process but that resulted in router hang. No firmware
related. Not sure if it was fixed.

2) jbemmel reported issue with card hang (not whole router), it
happened with messages: "Channel switch to default failed" /
"Microcode not responding". It was related to not allowed access to
B43_MMIO_PHY0 register. No firmware related. Fixed by updating
http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore

3) Now, (maybe) firmware related...

a) jbemmel switched to 4.150.10.5 and updated b43 at the same time and
reported success. No idea what really helped.

b) ldolse reported success when "building with the stable B43". Not
sure if he tried experimental.

c) anup.vasudev probably tried 4.150.10.5 but reported "It still dosent work"

d) linchen987 tried experimental firmware only and reported success
for AP, error for STA. Didn't compare to stable firmware.

e) zooloz tried experimental firmware reported success for few hours,
then duplicated "MAC suspend failed" messages. Didn't compare this to
stable firmware.

f) anonymous reported "This still dosent work with the latest build
from trunk.", even after trunk witched to stable firmware as default

g) metamatt posted some reports but he didn't give us direct hint
about firmware version.

So... generally we know nothing :| Not a single straight report about
relation between firmware and stability.

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

As one of the people why reported some of these issues, I am going to take
it upon my self to test the current b43 firmware with an ASUS WL500pv2.
 This uses the Broadcom 5354 SoC and has a LP-PHY with Both the
stable(4.150.10.5) and experimental (4.178.10.4) firmware.

I will report back in the next couple of days.

Cheers
----------------------------------------------------------
Chris Martin
m: 0419812371
----------------------------------------------------------


2011/3/2 Rafa? Mi?ecki <zajec5@gmail.com>

> W dniu 7 grudnia 2010 20:21 u?ytkownik Hauke Mehrtens
> <hauke@hauke-m.de> napisa?:
> > On 12/07/2010 04:32 PM, Larry Finger wrote:
> >> On 12/07/2010 06:28 AM, Rafa? Mi?ecki wrote:
> >>> W dniu 7 grudnia 2010 13:21 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com>
> napisa?:
> >>>> Currently we tell ppl to use 4.150.10.5 for G-PHY and 4.174.64.19 for
> >>>> LP-PHY on our wiki page.
> >>>>
> >>>> Firmware files for G-PHY differ a little between there two versions,
> >>>> but did we actually get any problems reports?
> >>>>
> >>>> Can we drop 4.150.10.5 description?
> >>>
> >>> openSUSE 11.3 seems to download 4.174.64.19 only with it's script and
> >>> I didn't heard about any reports. One more point for dropping
> >>> 4.150.10.5?
> >>
> >> I pushed the patch to change openSUSE's script early in the beta testing
> for
> >> that release. I have heard no complaints either. I agree that 4.150.10.5
> should
> >> be dropped.
>
> Sorry for responding so late, that bug reports scared me at first
> look, I switched to sth else to forgot that case.
>
>
> > We had serious issues with firmware version 4.174.64.19 in OpenWrt and
> > switched back to the old on as the default option. This issue afftected
> > mostly LP-PHY devices.
> >
> > See the Bug report: https://dev.openwrt.org/ticket/6907 This was with
> > kernel 2.6.32 and compat-wireless from  round about March to May 2010.
> > Stable means the old firmware version and experimental the new one in
> > the bug report.
>
> OK, I can see there are 2 bug reports:
> https://dev.openwrt.org/ticket/7117
> https://dev.openwrt.org/ticket/6907
>
> First one #7117 is about some memory leak and "page allocation
> failure" as a result. It really should have nothing to do with
> firmware, I guess we just had some memory leak in b43.
>
> Second one #6907 is much worse...
>
> 1) At beginning it's about hanging router, it seems to be also (the
> same?) memory leak. Probably scanning triggers it. Out of memory leads
> to killing process but that resulted in router hang. No firmware
> related. Not sure if it was fixed.
>
> 2) jbemmel reported issue with card hang (not whole router), it
> happened with messages: "Channel switch to default failed" /
> "Microcode not responding". It was related to not allowed access to
> B43_MMIO_PHY0 register. No firmware related. Fixed by updating
> http://bcm-v4.sipsolutions.net/802.11/PHY/Anacore
>
> 3) Now, (maybe) firmware related...
>
> a) jbemmel switched to 4.150.10.5 and updated b43 at the same time and
> reported success. No idea what really helped.
>
> b) ldolse reported success when "building with the stable B43". Not
> sure if he tried experimental.
>
> c) anup.vasudev probably tried 4.150.10.5 but reported "It still dosent
> work"
>
> d) linchen987 tried experimental firmware only and reported success
> for AP, error for STA. Didn't compare to stable firmware.
>
> e) zooloz tried experimental firmware reported success for few hours,
> then duplicated "MAC suspend failed" messages. Didn't compare this to
> stable firmware.
>
> f) anonymous reported "This still dosent work with the latest build
> from trunk.", even after trunk witched to stable firmware as default
>
> g) metamatt posted some reports but he didn't give us direct hint
> about firmware version.
>
> So... generally we know nothing :| Not a single straight report about
> relation between firmware and stability.
>
> --
> Rafa?
>
> _______________________________________________
> b43-dev mailing list
> b43-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110302/0b5e4bbb/attachment-0001.html>

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 2 marca 2011 01:11 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
> As one of the people why reported some of these issues, I am going to take
> it upon my self to test the current b43 firmware with an ASUS WL500pv2.
> ?This uses the Broadcom 5354 SoC and has a LP-PHY with Both the
> stable(4.150.10.5) and experimental?(4.178.10.4)?firmware.
> I will report back in the next couple of days.

Thanks. I believe OpenWRT doesn't have any special hacks, archiving
firmwares, etc. and you can simply replace files in your
/lib/firmware, without recompiling OpenWRT.

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/2 chris at martin.cc <chris@martin.cc>
>
> As one of the people why reported some of these issues, I am going to take it upon my self to
> test the current b43 firmware with an ASUS WL500pv2. ?This uses the Broadcom 5354 SoC and > has a LP-PHY with Both the stable(4.150.10.5) and experimental?(4.178.10.4)?firmware.

OK. ?I managed that faster that I expected
I tested the latest (fresh checkout) of OpenWrt backfire 10.03
I can confirm that when using the broadcom 5354 SoC (LP-PHY) that the
experimental??(4.178.10.4)?firmware. causes "oom" errors.
I repeated tests with both stable and experimental with the same
configuration and the
experimental version always caused "oom"

happy to test anything else as needed.  I currently have the stable
version under a load test

The following is the first "iteration" of the log - as up can see the
firmware is loaded.
The radio interface is added to the bridge and  moved to the
forwarding state, then POW.

b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
device wlan0 entered promiscuous mode
br-lan: port 2(wlan0) entering forwarding state
hotplug2 invoked oom-killer: gfp_mask=0x80d0, order=0, oom_adj=0
Call Trace:
[<8000a230>] dump_stack+0x8/0x34
[<80063280>] oom_kill_process+0x68/0x200
[<800639f8>] __out_of_memory+0x17c/0x1b0
[<80063a9c>] out_of_memory+0x70/0xa0
[<800677a4>] __alloc_pages_nodemask+0x4bc/0x5e8
[<800678e8>] __get_free_pages+0x18/0x50
[<800e5820>] sysfs_read_file+0x8c/0x174
[<800968b0>] sys_read+0x58/0x9c
[<80003230>] stack_done+0x20/0x3c
Mem-Info:
Normal per-cpu:
CPU ? ?0: hi: ? ?0, btch: ? 1 usd: ? 0
active_anon:387 inactive_anon:428 isolated_anon:0
?active_file:15 inactive_file:42 isolated_file:0
?unevictable:0 dirty:0 writeback:0 unstable:0
?free:172 slab_reclaimable:163 slab_unreclaimable:5627
?mapped:52 shmem:49 pagetables:70 bounce:0
Normal free:688kB min:720kB low:900kB high:1080kB active_anon:1548kB
inactive_anon:1712kB active_file:60kB inactive_file:168kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:32512kB
mlocked:0kB dirty:0kB writeback:0kB mapped:208kB shmem:196kB
slab_reclaimable:652kB slab_unreclaimable:22508kB kernel_stack:312kB
pagetables:280kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:81 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 32*4kB 0*8kB 1*16kB 1*32kB 0*64kB 0*128kB 0*256kB 1*512kB
0*1024kB 0*2048kB 0*4096kB = 688kB
106 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap ?= 0kB
Total swap = 0kB
8192 pages RAM
790 pages reserved
507 pages shared
7011 pages non-shared
Out of memory: kill process 664 (dnsmasq) score 228 or a child
Killed process 664 (dnsmasq)

Cheers
----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 2 marca 2011 04:30 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
> 2011/3/2 chris at martin.cc <chris@martin.cc>
>>
>> As one of the people why reported some of these issues, I am going to take it upon my self to
>> test the current b43 firmware with an ASUS WL500pv2. ?This uses the Broadcom 5354 SoC and > has a LP-PHY with Both the stable(4.150.10.5) and experimental?(4.178.10.4)?firmware.
>
> OK. ?I managed that faster that I expected
> I tested the latest (fresh checkout) of OpenWrt backfire 10.03
> I can confirm that when using the broadcom 5354 SoC (LP-PHY) that the
> experimental??(4.178.10.4)?firmware. causes "oom" errors.
> I repeated tests with both stable and experimental with the same
> configuration and the
> experimental version always caused "oom"
>
> happy to test anything else as needed. ?I currently have the stable
> version under a load test
>
> The following is the first "iteration" of the log - as up can see the
> firmware is loaded.
> The radio interface is added to the bridge and ?moved to the
> forwarding state, then POW.
>
> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> device wlan0 entered promiscuous mode
> br-lan: port 2(wlan0) entering forwarding state
> hotplug2 invoked oom-killer: gfp_mask=0x80d0, order=0, oom_adj=0

Thanks for your tests!

I really need some help now. Does anyone have idea how changing
firmware can cause out of memory on host? I try to imagine some
reasons...
1) We detect some problem with hw/fw (correctly or not) and go into
some infinity recursion
2) Newer firmware does sth differently with DMA, we allocate too much?
OK, there is not even point "3" from me. I have no more ideas :|

I could check than new vs. old firmware on my only LP-PHY, but how can
I check for memory allocated by module? lsmod displays column "size"
but I don't think it's about memory.

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 2 marca 2011 10:58 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> W dniu 2 marca 2011 04:30 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
>> 2011/3/2 chris at martin.cc <chris@martin.cc>
>>>
>>> As one of the people why reported some of these issues, I am going to take it upon my self to
>>> test the current b43 firmware with an ASUS WL500pv2. ?This uses the Broadcom 5354 SoC and > has a LP-PHY with Both the stable(4.150.10.5) and experimental?(4.178.10.4)?firmware.
>>
>> OK. ?I managed that faster that I expected
>> I tested the latest (fresh checkout) of OpenWrt backfire 10.03
>> I can confirm that when using the broadcom 5354 SoC (LP-PHY) that the
>> experimental??(4.178.10.4)?firmware. causes "oom" errors.
>> I repeated tests with both stable and experimental with the same
>> configuration and the
>> experimental version always caused "oom"
>>
>> happy to test anything else as needed. ?I currently have the stable
>> version under a load test
>>
>> The following is the first "iteration" of the log - as up can see the
>> firmware is loaded.
>> The radio interface is added to the bridge and ?moved to the
>> forwarding state, then POW.
>>
>> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>> device wlan0 entered promiscuous mode
>> br-lan: port 2(wlan0) entering forwarding state
>> hotplug2 invoked oom-killer: gfp_mask=0x80d0, order=0, oom_adj=0
>
> Thanks for your tests!
>
> I really need some help now. Does anyone have idea how changing
> firmware can cause out of memory on host? I try to imagine some
> reasons...
> 1) We detect some problem with hw/fw (correctly or not) and go into
> some infinity recursion
> 2) Newer firmware does sth differently with DMA, we allocate too much?
> OK, there is not even point "3" from me. I have no more ideas :|

I checked for kernels in OpenWRT.
OpenWRT 10.03 is 2.6.32.10
OpenWRT 10.03.1-rc4 is 2.6.32.25

I can see 2.6.32(.0) at least have:
b43: Add LP PHY Analog Switch Support
that's good.

Maybe compiling b43 with debugging could help to understand what is
going on? Could insmod b43.ko pio=1 be workaround?

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[Jonas Gorski]

2011/3/2 Rafa? Mi?ecki <zajec5@gmail.com>:
> I checked for kernels in OpenWRT.
> OpenWRT 10.03 is 2.6.32.10
> OpenWRT 10.03.1-rc4 is 2.6.32.25
>
> I can see 2.6.32(.0) at least have:
> b43: Add LP PHY Analog Switch Support
> that's good.

Note that OpenWrt does not use the in-kernel drivers but uses
compat-wireless (except for SSB). 10.03 uses compat-wireless
2010-03-24, while 10.03.1-rc4 uses 2010-10-19. The backfire branch
itself is currently at 2011-02-07.

Regards,
Jonas Gorski

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/2 Rafa? Mi?ecki <zajec5@gmail.com>:
>
> I checked for kernels in OpenWRT.
> OpenWRT 10.03 is 2.6.32.10
> OpenWRT 10.03.1-rc4 is 2.6.32.25
>
> I can see 2.6.32(.0) at least have:
> b43: Add LP PHY Analog Switch Support
> that's good.
>
> Maybe compiling b43 with debugging could help to understand what is
> going on? Could insmod b43.ko pio=1 be workaround?
>

Just to clarify.  I tested 10.03-rc4 - and trunk wicth is 2.6.36.x
I will also confirm the versions tomorrow

----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------

Switching to 4.174.64.19 firmware for G-PHY cards?

[Larry Finger]

On 03/02/2011 06:20 AM, chris at martin.cc wrote:
> 2011/3/2 Rafa? Mi?ecki<zajec5@gmail.com>:
>>
>> I checked for kernels in OpenWRT.
>> OpenWRT 10.03 is 2.6.32.10
>> OpenWRT 10.03.1-rc4 is 2.6.32.25
>>
>> I can see 2.6.32(.0) at least have:
>> b43: Add LP PHY Analog Switch Support
>> that's good.
>>
>> Maybe compiling b43 with debugging could help to understand what is
>> going on? Could insmod b43.ko pio=1 be workaround?
>>
>
> Just to clarify.  I tested 10.03-rc4 - and trunk wicth is 2.6.36.x
> I will also confirm the versions tomorrow

Chris,

This problem is getting more and more curious.

I have two systems with 14e4:4315 LP PHY cards. One is x86_64 and the other is 
i386. I added kmemleak checking to each and have been running networking for 
about 3 hours on the 64-bit system, and 18 hours for 32 bit. Neither shows any 
memory leaks associated with b43. Both are using 508.1084 firmware. Most of the 
tests were in STA mode, but a few minutes with one hosting an AP for the other 
has not shown any leaks.

I imagine that memory is pretty tight on the openWRT system. Does "free" work 
there? If so, what are the results just before you start the bridging?

Larry

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------



On Thu, Mar 3, 2011 at 9:00 AM, Larry Finger <Larry.Finger@lwfinger.net>
wrote:
> On 03/02/2011 06:20 AM, chris at martin.cc wrote:
>>
>> 2011/3/2 Rafa? Mi?ecki<zajec5@gmail.com>:
>>>
>>> I checked for kernels in OpenWRT.
>>> OpenWRT 10.03 is 2.6.32.10
>>> OpenWRT 10.03.1-rc4 is 2.6.32.25
>>>
>>> I can see 2.6.32(.0) at least have:
>>> b43: Add LP PHY Analog Switch Support
>>> that's good.
>>>
>>> Maybe compiling b43 with debugging could help to understand what is
>>> going on? Could insmod b43.ko pio=1 be workaround?
>>>
>>
>> Just to clarify.  I tested 10.03-rc4 - and trunk wicth is 2.6.36.x
>> I will also confirm the versions tomorrow
>
> Chris,
>
> This problem is getting more and more curious.
>
> I have two systems with 14e4:4315 LP PHY cards. One is x86_64 and the
other
> is i386. I added kmemleak checking to each and have been running
networking
> for about 3 hours on the 64-bit system, and 18 hours for 32 bit. Neither
> shows any memory leaks associated with b43. Both are using 508.1084
> firmware. Most of the tests were in STA mode, but a few minutes with one
> hosting an AP for the other has not shown any leaks.
>
> I imagine that memory is pretty tight on the openWRT system. Does "free"
> work there? If so, what are the results just before you start the
bridging?
>
> Larry

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

On Thu, Mar 3, 2011 at 9:00 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 03/02/2011 06:20 AM, chris at martin.cc wrote:
>>
> This problem is getting more and more curious.
>
> I have two systems with 14e4:4315 LP PHY cards. One is x86_64 and the other
> is i386. I added kmemleak checking to each and have been running networking
> for about 3 hours on the 64-bit system, and 18 hours for 32 bit. Neither
> shows any memory leaks associated with b43. Both are using 508.1084
> firmware. Most of the tests were in STA mode, but a few minutes with one
> hosting an AP for the other has not shown any leaks.

I configured it to run in Client(STA) mode and I still has the same
problem.  However I did get a little more information

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

----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

2011/3/3 chris at martin.cc <chris@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.

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 3 marca 2011 08:58 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> 2011/3/3 chris at martin.cc <chris@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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lp.tx.ctl1.patch
Type: application/octet-stream
Size: 917 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110303/6e7792df/attachment.obj>

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/3 Rafa? Mi?ecki <zajec5@gmail.com>:
> W dniu 3 marca 2011 08:58 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>> 2011/3/3 chris at martin.cc <chris@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



----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------

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@martin.cc> napisa?:
> 2011/3/3 Rafa? Mi?ecki <zajec5@gmail.com>:
>> W dniu 3 marca 2011 08:58 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>>> 2011/3/3 chris at martin.cc <chris@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?

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/3 Rafa? Mi?ecki <zajec5@gmail.com>:
>
> 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.
>

Maybe the way to investigate this further is to look at what is being
passed between
mac80211 and b43, with the different firmwares.

I will add some debugging on the weekend and see what I can uncover.

----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 4 marca 2011 01:37 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
> 2011/3/3 Rafa? Mi?ecki <zajec5@gmail.com>:
>>
>> 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.
>>
>
> Maybe the way to investigate this further is to look at what is being
> passed between
> mac80211 and b43, with the different firmwares.
>
> I will add some debugging on the weekend and see what I can uncover.

Did you play with that bug over weekend? Any news?

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/7 Rafa? Mi?ecki <zajec5@gmail.com>

> W dniu 4 marca 2011 01:37 u?ytkownik chris at martin.cc <chris@martin.cc>
> napisa?:
> > 2011/3/3 Rafa? Mi?ecki <zajec5@gmail.com>:
> >>
> >> 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.
> >>
> >
> > Maybe the way to investigate this further is to look at what is being
> > passed between
> > mac80211 and b43, with the different firmwares.
> >
> > I will add some debugging on the weekend and see what I can uncover.
>
> Did you play with that bug over weekend? Any news?
>


Sorry,  but no, I didn't get a chance.  I will in the next day or two.
I am planning to log all the ops functions and all the ieee80211 functions.
and then compare the logs between the stable and experimental firmware.

----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110308/4593f1bc/attachment-0001.html>

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 4 marca 2011 01:37 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
> Maybe the way to investigate this further is to look at what is being
> passed between
> mac80211 and b43, with the different firmwares.
>
> I will add some debugging on the weekend and see what I can uncover.

Maybe it'd make sense to check what we get from hardware with older
vs. newer firmware?

Attached patch was compile-tested only.

It may put a lot of messages in your dmesg, don't try to run it for too long ;)

-- 
Rafa?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmit.track.patch
Type: application/octet-stream
Size: 48 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110307/0b0deefe/attachment.obj>

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 7 marca 2011 14:12 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> W dniu 4 marca 2011 01:37 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
>> Maybe the way to investigate this further is to look at what is being
>> passed between
>> mac80211 and b43, with the different firmwares.
>>
>> I will add some debugging on the weekend and see what I can uncover.
>
> Maybe it'd make sense to check what we get from hardware with older
> vs. newer firmware?
>
> Attached patch was compile-tested only.
>
> It may put a lot of messages in your dmesg, don't try to run it for too long ;)

I didn't see real differences between 410.2160 and 478.104 on my
14e4:4315 (BCM4312) with this patch :(

Maybe your card will behave differently and will show us sth? :(

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/8 Rafa? Mi?ecki <zajec5@gmail.com>

> W dniu 4 marca 2011 01:37 u?ytkownik chris at martin.cc <chris@martin.cc>
> napisa?:
> > Maybe the way to investigate this further is to look at what is being
> > passed between
> > mac80211 and b43, with the different firmwares.
> >
> > I will add some debugging on the weekend and see what I can uncover.
>
> Maybe it'd make sense to check what we get from hardware with older
> vs. newer firmware?
>
> Attached patch was compile-tested only.
>
> It may put a lot of messages in your dmesg, don't try to run it for too
> long ;)
>
>
Rafal

I think something went wrong with the patch you attached.
when I detach it, it contains

  Building modules, stage 2.
  MODPOST 1 modules

And nothing else.


Further..  When I was testing the driver (both in AP and STA modes) I had it
disconnected form the network, and disconnected from the bridge.  As a
result there would have been very little data transmitted.  However there is
lots of 802.11 traffic in the air.  So I think that we will find the problem
on the receive path rather than the transmit path,  Just my 2c worth until I
get some logging in there.


----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110308/bb28d478/attachment.html>

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 8 marca 2011 02:25 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
>
> 2011/3/8 Rafa? Mi?ecki <zajec5@gmail.com>
>>
>> W dniu 4 marca 2011 01:37 u?ytkownik chris at martin.cc <chris@martin.cc>
>> napisa?:
>> > Maybe the way to investigate this further is to look at what is being
>> > passed between
>> > mac80211 and b43, with the different firmwares.
>> >
>> > I will add some debugging on the weekend and see what I can uncover.
>>
>> Maybe it'd make sense to check what we get from hardware with older
>> vs. newer firmware?
>>
>> Attached patch was compile-tested only.
>>
>> It may put a lot of messages in your dmesg, don't try to run it for too
>> long ;)
>>
>
> Rafal
> I think?something?went wrong with the patch you attached.
> when I detach it, it contains
>
> ??Building modules, stage 2.
> ??MODPOST 1 modules
> And nothing else.
>
> Further.. ?When I was testing the driver (both in AP and STA modes) I had it
> disconnected form the network, and disconnected from the bridge. ?As a
> result there would have been very little data transmitted. ?However there is
> lots of 802.11 traffic in the air. ?So I think that we will find the problem
> on the receive path rather than the transmit path, ?Just my 2c worth until I
> get some logging in there.

Whoops, sorry. Can you try attached patch? And compare old and new
firmware with this patch applied?

As you can see from one of my prev mail, I also suspect RX. That's why
patch tries to print some info about RX, headers we receive from
firmware.

-- 
Rafa?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmit.dbg.patch
Type: application/octet-stream
Size: 1225 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110308/9add0483/attachment.obj>

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/9 Rafa? Mi?ecki <zajec5@gmail.com>

> W dniu 8 marca 2011 02:25 u?ytkownik chris at martin.cc <chris@martin.cc>
> napisa?:
> >
> > 2011/3/8 Rafa? Mi?ecki <zajec5@gmail.com>
> >>
> >> W dniu 4 marca 2011 01:37 u?ytkownik chris at martin.cc <chris@martin.cc>
> >> napisa?:
> >> > Maybe the way to investigate this further is to look at what is being
> >> > passed between
> >> > mac80211 and b43, with the different firmwares.
> >> >
> >> > I will add some debugging on the weekend and see what I can uncover.
> >>
> >> Maybe it'd make sense to check what we get from hardware with older
> >> vs. newer firmware?
> >>
> >> Attached patch was compile-tested only.
> >>
> >> It may put a lot of messages in your dmesg, don't try to run it for too
> >> long ;)
> >>
>

I the just tested the patch
Very curious..  I get nothing.

I double checked that the patch was applied.
I cleaned the object files, to ensure that it was compiled
I ensured that CONFIG_B43_DEBUG was enabled

But the lines are never called

----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110309/be0cd511/attachment.html>

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 9 marca 2011 01:44 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
> 2011/3/9 Rafa? Mi?ecki <zajec5@gmail.com>
>>
>> W dniu 8 marca 2011 02:25 u?ytkownik chris at martin.cc <chris@martin.cc>
>> napisa?:
>> >
>> > 2011/3/8 Rafa? Mi?ecki <zajec5@gmail.com>
>> >>
>> >> W dniu 4 marca 2011 01:37 u?ytkownik chris at martin.cc <chris@martin.cc>
>> >> napisa?:
>> >> > Maybe the way to investigate this further is to look at what is being
>> >> > passed between
>> >> > mac80211 and b43, with the different firmwares.
>> >> >
>> >> > I will add some debugging on the weekend and see what I can uncover.
>> >>
>> >> Maybe it'd make sense to check what we get from hardware with older
>> >> vs. newer firmware?
>> >>
>> >> Attached patch was compile-tested only.
>> >>
>> >> It may put a lot of messages in your dmesg, don't try to run it for too
>> >> long ;)
>> >>
>
> I the just tested the patch
> Very curious.. ?I get nothing.
> I double checked that the patch was applied.
> I cleaned the object files, to ensure that it was?compiled
> I ensured that CONFIG_B43_DEBUG was enabled
> But the lines are never called

With which firmware did you test?

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/9 chris at martin.cc <chris@martin.cc>

> 2011/3/9 Rafa? Mi?ecki <zajec5@gmail.com>
>
> W dniu 8 marca 2011 02:25 u?ytkownik chris at martin.cc <chris@martin.cc>
>> napisa?:
>> >
>> > 2011/3/8 Rafa? Mi?ecki <zajec5@gmail.com>
>> >>
>> >> W dniu 4 marca 2011 01:37 u?ytkownik chris at martin.cc <chris@martin.cc>
>> >> napisa?:
>> >> > Maybe the way to investigate this further is to look at what is being
>> >> > passed between
>> >> > mac80211 and b43, with the different firmwares.
>> >> >
>> >> > I will add some debugging on the weekend and see what I can uncover.
>> >>
>> >> Maybe it'd make sense to check what we get from hardware with older
>> >> vs. newer firmware?
>> >>
>> >> Attached patch was compile-tested only.
>> >>
>> >> It may put a lot of messages in your dmesg, don't try to run it for too
>> >> long ;)
>> >>
>>
>
> I the just tested the patch
> Very curious..  I get nothing.
>
> I double checked that the patch was applied.
> I cleaned the object files, to ensure that it was compiled
> I ensured that CONFIG_B43_DEBUG was enabled
>
> But the lines are never called
>

I also tried both experimental and stable, with the same result
----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110309/c876d564/attachment.html>

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

I don't know if this is useful, but after the oom killer has destroyed
all the process the console log loops on the following message:

irq/5-b43: 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
[<81a14220>] 0x81a14220

Mem-Info:
Normal per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
active_anon:90 inactive_anon:140 isolated_anon:0
 active_file:3 inactive_file:3 isolated_file:0
 unevictable:0 dirty:0 writeback:0 unstable:0
 free:70 slab_reclaimable:116 slab_unreclaimable:6370
 mapped:4 shmem:10 pagetables:38 bounce:0
Normal free:280kB min:720kB low:900kB high:1080kB active_anon:360kB
inactive_anon:560kB active_file:12kB inactive_file:12kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:32512kB
mlocked:0kB dirty:0kB writeback:0kB mapped:16kB shmem:40kB
slab_reclaimable:464kB slab_unreclaimable:25480kB kernel_stack:488kB
pagetables:152kB unstable:0kB bounce:0kB writeback_tmp:0kB
pages_scanned:36 all_unreclaimable? yes
lowmem_reserve[]: 0 0
Normal: 0*4kB 1*8kB 1*16kB 0*32kB 0*64kB 0*128kB 1*256kB 0*512kB
0*1024kB 0*2048kB 0*4096kB = 280kB
16 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
8192 pages RAM
757 pages reserved
25 pages shared
7201 pages non-shared


----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/2 chris at martin.cc <chris@martin.cc>:
> 2011/3/2 Rafa? Mi?ecki <zajec5@gmail.com>:
>>
>> I checked for kernels in OpenWRT.
>> OpenWRT 10.03 is 2.6.32.10
>> OpenWRT 10.03.1-rc4 is 2.6.32.25
>>
>> I can see 2.6.32(.0) at least have:
>> b43: Add LP PHY Analog Switch Support
>> that's good.
>>
>> Maybe compiling b43 with debugging could help to understand what is
>> going on? Could insmod b43.ko pio=1 be workaround?
>>
>
> Just to clarify. ?I tested 10.03-rc4 - and trunk wicth is 2.6.36.x
> I will also confirm the versions tomorrow

OpenWrt trunk         2.6.36.4
OpenWrt 10.03-rc4   2.6.32.27


----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/2 Rafa? Mi?ecki <zajec5@gmail.com>
>
> W dniu 2 marca 2011 04:30 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
> > 2011/3/2 chris at martin.cc <chris@martin.cc>
> >>
> >> As one of the people why reported some of these issues, I am going to take it upon my self to
> >> test the current b43 firmware with an ASUS WL500pv2. ?This uses the Broadcom 5354 SoC and > has a LP-PHY with Both the stable(4.150.10.5) and experimental?(4.178.10.4)?firmware.
> >
> > OK. ?I managed that faster that I expected
> > I tested the latest (fresh checkout) of OpenWrt backfire 10.03
> > I can confirm that when using the broadcom 5354 SoC (LP-PHY) that the
> > experimental??(4.178.10.4)?firmware. causes "oom" errors.
> > I repeated tests with both stable and experimental with the same
> > configuration and the
> > experimental version always caused "oom"
> >
> > happy to test anything else as needed. ?I currently have the stable
> > version under a load test
> >
> > The following is the first "iteration" of the log - as up can see the
> > firmware is loaded.
> > The radio interface is added to the bridge and ?moved to the
> > forwarding state, then POW.
> >
> > b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> > b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> > device wlan0 entered promiscuous mode
> > br-lan: port 2(wlan0) entering forwarding state
> > hotplug2 invoked oom-killer: gfp_mask=0x80d0, order=0, oom_adj=0
>
> Thanks for your tests!
>
> I really need some help now. Does anyone have idea how changing
> firmware can cause out of memory on host? I try to imagine some
> reasons...
> 1) We detect some problem with hw/fw (correctly or not) and go into
> some infinity recursion
> 2) Newer firmware does sth differently with DMA, we allocate too much?
> OK, there is not even point "3" from me. I have no more ideas :|
>
> I could check than new vs. old firmware on my only LP-PHY, but how can
> I check for memory allocated by module? lsmod displays column "size"
> but I don't think it's about memory.
>

I did look in the source and found that there where 3 locations that
kmalloc() was called,
I added a printk(KERN_CRIT), just before each so I could determine so
that it would be displayed on the console.
But I didn't get anything.  So it must be in a tight loop.  And I'm
pretty sure that it is triggered by a packet being sent to the radio
from the bridge.
I did notice that there was some debug options so I will have a look
at that tomorrow.

----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 2 marca 2011 13:14 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
> 2011/3/2 Rafa? Mi?ecki <zajec5@gmail.com>
>>
>> W dniu 2 marca 2011 04:30 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
>> > 2011/3/2 chris at martin.cc <chris@martin.cc>
>> >>
>> >> As one of the people why reported some of these issues, I am going to take it upon my self to
>> >> test the current b43 firmware with an ASUS WL500pv2. ?This uses the Broadcom 5354 SoC and > has a LP-PHY with Both the stable(4.150.10.5) and experimental?(4.178.10.4)?firmware.
>> >
>> > OK. ?I managed that faster that I expected
>> > I tested the latest (fresh checkout) of OpenWrt backfire 10.03
>> > I can confirm that when using the broadcom 5354 SoC (LP-PHY) that the
>> > experimental??(4.178.10.4)?firmware. causes "oom" errors.
>> > I repeated tests with both stable and experimental with the same
>> > configuration and the
>> > experimental version always caused "oom"
>> >
>> > happy to test anything else as needed. ?I currently have the stable
>> > version under a load test
>> >
>> > The following is the first "iteration" of the log - as up can see the
>> > firmware is loaded.
>> > The radio interface is added to the bridge and ?moved to the
>> > forwarding state, then POW.
>> >
>> > b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>> > b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>> > device wlan0 entered promiscuous mode
>> > br-lan: port 2(wlan0) entering forwarding state
>> > hotplug2 invoked oom-killer: gfp_mask=0x80d0, order=0, oom_adj=0
>>
>> Thanks for your tests!
>>
>> I really need some help now. Does anyone have idea how changing
>> firmware can cause out of memory on host? I try to imagine some
>> reasons...
>> 1) We detect some problem with hw/fw (correctly or not) and go into
>> some infinity recursion
>> 2) Newer firmware does sth differently with DMA, we allocate too much?
>> OK, there is not even point "3" from me. I have no more ideas :|
>>
>> I could check than new vs. old firmware on my only LP-PHY, but how can
>> I check for memory allocated by module? lsmod displays column "size"
>> but I don't think it's about memory.
>>
>
> I did look in the source and found that there where 3 locations that
> kmalloc() was called,
> I added a printk(KERN_CRIT), just before each so I could determine so
> that it would be displayed on the console.
> But I didn't get anything. ?So it must be in a tight loop. ?And I'm
> pretty sure that it is triggered by a packet being sent to the radio
> from the bridge.
> I did notice that there was some debug options so I will have a look
> at that tomorrow.

There are many more allocs, for example: kzalloc, kmalloc. Could you
put print before them as well?

Also: could you try loading b43 with pio mode instead of dma? To do this:
rmmod b43
rmmod ssb
insmod /lib/modules/2.6.32.x/b43.ko pio=1

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[Jonas Gorski]

2011/3/2 Rafa? Mi?ecki <zajec5@gmail.com>:
> Also: could you try loading b43 with pio mode instead of dma? To do this:
> rmmod b43
> rmmod ssb
> insmod /lib/modules/2.6.32.x/b43.ko pio=1

pio support seems to removed in OpenWrt; to make this work it you
probably need to remove package/mac80211/patches/810-b43_no_pio.patch
and then recompile mac80211.

Regards,
Jonas Gorski

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/3 Rafa? Mi?ecki <zajec5@gmail.com>

> W dniu 2 marca 2011 13:14 u?ytkownik chris at martin.cc <chris@martin.cc>
> napisa?:
> > 2011/3/2 Rafa? Mi?ecki <zajec5@gmail.com>
> >>
> >> W dniu 2 marca 2011 04:30 u?ytkownik chris at martin.cc <chris@martin.cc>
> napisa?:
> >> > 2011/3/2 chris at martin.cc <chris@martin.cc>
> >> >>
> >> >> As one of the people why reported some of these issues, I am going to
> take it upon my self to
> >> >> test the current b43 firmware with an ASUS WL500pv2.  This uses the
> Broadcom 5354 SoC and > has a LP-PHY with Both the stable(4.150.10.5) and
> experimental (4.178.10.4) firmware.
> >> >
> >> > OK.  I managed that faster that I expected
> >> > I tested the latest (fresh checkout) of OpenWrt backfire 10.03
> >> > I can confirm that when using the broadcom 5354 SoC (LP-PHY) that the
> >> > experimental  (4.178.10.4) firmware. causes "oom" errors.
> >> > I repeated tests with both stable and experimental with the same
> >> > configuration and the
> >> > experimental version always caused "oom"
> >> >
> >> > happy to test anything else as needed.  I currently have the stable
> >> > version under a load test
> >> >
> >> > The following is the first "iteration" of the log - as up can see the
> >> > firmware is loaded.
> >> > The radio interface is added to the bridge and  moved to the
> >> > forwarding state, then POW.
> >> >
> >> > b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> >> > b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> >> > device wlan0 entered promiscuous mode
> >> > br-lan: port 2(wlan0) entering forwarding state
> >> > hotplug2 invoked oom-killer: gfp_mask=0x80d0, order=0, oom_adj=0
> >>
> >> Thanks for your tests!
> >>
> >> I really need some help now. Does anyone have idea how changing
> >> firmware can cause out of memory on host? I try to imagine some
> >> reasons...
> >> 1) We detect some problem with hw/fw (correctly or not) and go into
> >> some infinity recursion
> >> 2) Newer firmware does sth differently with DMA, we allocate too much?
> >> OK, there is not even point "3" from me. I have no more ideas :|
> >>
> >> I could check than new vs. old firmware on my only LP-PHY, but how can
> >> I check for memory allocated by module? lsmod displays column "size"
> >> but I don't think it's about memory.
> >>
> >
> > I did look in the source and found that there where 3 locations that
> > kmalloc() was called,
> > I added a printk(KERN_CRIT), just before each so I could determine so
> > that it would be displayed on the console.
> > But I didn't get anything.  So it must be in a tight loop.  And I'm
> > pretty sure that it is triggered by a packet being sent to the radio
> > from the bridge.
> > I did notice that there was some debug options so I will have a look
> > at that tomorrow.
>
> There are many more allocs, for example: kzalloc, kmalloc. Could you
> put print before them as well?
>

A bug in the compiler was discovered the other day.  It is associated with
an optimisation. A patch has been created and applied to OpenWrt trunk.  I
have updated everything, rebuilt the toolchain, and the firmware.  The same
problem still occurs - So its not the compiler bug.

I have located all the kmalloc() and kzalloc() calls and added a printf.

On loading I get.

Compat-wireless backport release: compat-wireless-2011-01-31-19-g74d6d79
Backport based on wireless-testing.git master-2011-02-25
cfg80211: Calling CRDA to update world regulatory domain
b43-phy0: Broadcom 5354 WLAN found (core revision 13)
compat-wireless-2011-02-25/drivers/net/wireless/b43/main.c:4885 kzalloc 772
bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/phy_lp.c:58 kzalloc 188
bytes
Broadcom 43xx driver loaded [ Features: PL, GPIO LED Mask: 0x000f,
Firmware-ID: FW13 ]

When the wireless interface is configured and added to the bridge

 root at OpenWrt:/etc/config# wifi up
Configuration file: /var/run/hostapd-phy0.conf
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 60
bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60
bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60
bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60
bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60
bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60
bytes
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 60
bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60
bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60
bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60
bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60
bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60
bytes
device wlan0 entered promiscuous mode
br-lan: port 2(wlan0) entering forwarding state
br-lan: port 2(wlan0) entering forwarding state
Using interface wlan0 with hwaddr 00:22:15:5c:e5:82 and ssid 'OpenWrt'
hotplug2 invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0,
oom_score_adj=0
Call Trace:
[<80009120>] dump_stack+0x8/0x34
[<8005f828>] dump_header.clone.13+0x4c/0x120
[<8005fa50>] oom_kill_process.clone.15+0x5c/0x2b4
[<800601f8>] out_of_memory+0x2d4/0x364
[<80064074>] __alloc_pages_nodemask+0x45c/0x570
[<80066a44>] __do_page_cache_readahead+0xd4/0x29c
[<80066fd8>] ra_submit+0x28/0x34
[<8005ccec>] filemap_fault+0x280/0x508
[<800775d0>] __do_fault+0x70/0x6e8
[<8007b198>] handle_mm_fault+0x3b0/0x7ec
[<80016a00>] do_page_fault+0x100/0x2e0
[<80001820>] ret_from_exception+0x0/0x24

I notice that the first time the interface is brought up that there is an
extra kzalloc() for 332 bytes, but this may be a side effect of different
commands/configuration being issued against the device.

----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20110303/0ead56f9/attachment-0001.html>

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 3 marca 2011 04:40 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
> 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 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60 bytes
> 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 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60 bytes
> compat-wireless-2011-02-25/drivers/net/wireless/b43/dma.c:824 kzalloc 60 bytes

2011/3/3 chris at martin.cc <chris@martin.cc>:
> 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

824 line is:
[struct b43_dmaring *]ring = kzalloc(sizeof(*ring), GFP_KERNEL);

Does anyone know why sometime we allocate 60b and sometimes 96b? It's
always the same struct... :| Could be STA vs. AP related but... how? I
don't see a way.

Chris: you didn't follow kcalloc-s with debugging messages. I can see
that from lack of debugging for dma.c:832:
ring->meta = kcalloc(ring->nr_slots, sizeof(struct b43_dmadesc_meta),
GFP_KERNEL);
The kcalloc-s in dma.c should not matter as they are only executed
together with your's kzalloc (dma.c:824).
The one in phy_lp.c has nice "free", should be safe, unless we hit
some infinity loop.

So it seems there is not any allocation bug in b43...

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[Larry Finger]

On 03/03/2011 01:55 AM, Rafa? Mi?ecki wrote:
> 824 line is:
> [struct b43_dmaring *]ring = kzalloc(sizeof(*ring), GFP_KERNEL);
>
> Does anyone know why sometime we allocate 60b and sometimes 96b? It's
> always the same struct... :| Could be STA vs. AP related but... how? I
> don't see a way.

It depends on whether CONFIG_B43_DEBUG is defined.

As you hint at later, Chris's memory problem is not due to a direct allocation 
problem, but is due to indirect allocation of skb or some other type of buffer. 
Why they leak on his system, and not on mine is a puzzle.

Larry

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/3 Rafa? Mi?ecki <zajec5@gmail.com>:
>
> Also: could you try loading b43 with pio mode instead of dma? To do this:
> rmmod b43
> rmmod ssb
> insmod /lib/modules/2.6.32.x/b43.ko pio=1
>

I reversed the "810-b43_no_pio.patch" patch as Jonas recommended
I also set CONFIG_B43_FORCE_PIO=y
the recompiled.

Just to be sure I also loaded with
    b43 pio=1

NOTE: there is no ssb module in OpenWrt.  perhaps its built in or
included in another module, I'm not sure

I still get the same OoM error, all be it a little bit latter.

The kzalloc() messages are now from the file pio.c - so I'm very sure
that its using polled I/O

root at OpenWrt:/# wifi up
Configuration file: /var/run/hostapd-phy0.conf
compat-wireless-2011-02-25/drivers/net/wireless/b43/main.c:2260
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/pio.c:143 kzalloc 668 bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/pio.c:143 kzalloc 668 bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/pio.c:143 kzalloc 668 bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/pio.c:143 kzalloc 668 bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/pio.c:143 kzalloc 668 bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/pio.c:178 kzalloc 8 bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/main.c:2260
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/pio.c:143 kzalloc 668 bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/pio.c:143 kzalloc 668 bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/pio.c:143 kzalloc 668 bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/pio.c:143 kzalloc 668 bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/pio.c:143 kzalloc 668 bytes
compat-wireless-2011-02-25/drivers/net/wireless/b43/pio.c:178 kzalloc 8 bytes
device wlan0 entered promiscuous mode
br-lan: port 2(wlan0) entering forwarding state
br-lan: port 2(wlan0) entering forwarding state
Using interface wlan0 with hwaddr 00:22:15:5c:e5:82 and ssid 'OpenWrt'
device wlan0 left promiscuous mode
br-lan: port 2(wlan0) entering forwarding state
device wlan0 entered promiscuous mode
br-lan: port 2(wlan0) entering forwarding state
br-lan: port 2(wlan0) entering forwarding state
kworker/0:15 invoked oom-killer: gfp_mask=0xd0, order=0, oom_adj=0,
oom_score_adj=0
Call Trace:
[<80009120>] dump_stack+0x8/0x34
[<8005f828>] dump_header.clone.13+0x4c/0x120
[<8005fa50>] oom_kill_process.clone.15+0x5c/0x2b4
[<800601f8>] out_of_memory+0x2d4/0x364
[<80064074>] __alloc_pages_nodemask+0x45c/0x570
[<8008d214>] cache_alloc_refill+0x280/0x740
[<8008d880>] kmem_cache_alloc+0x84/0xf4
[<80188a38>] skb_clone+0xdc/0x120
[<80117520>] broadcast_uevent+0x64/0xe0
[<81a14678>] 0x81a14678


----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/2 chris at martin.cc <chris@martin.cc>:
> 2011/3/2 Rafa? Mi?ecki <zajec5@gmail.com>
>>
>> W dniu 2 marca 2011 04:30 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
>> > 2011/3/2 chris at martin.cc <chris@martin.cc>
>> >>
>> >> As one of the people why reported some of these issues, I am going to take it upon my self to
>> >> test the current b43 firmware with an ASUS WL500pv2. ?This uses the Broadcom 5354 SoC and > has a LP-PHY with Both the stable(4.150.10.5) and experimental?(4.178.10.4)?firmware.
>> >
>> > OK. ?I managed that faster that I expected
>> > I tested the latest (fresh checkout) of OpenWrt backfire 10.03
>> > I can confirm that when using the broadcom 5354 SoC (LP-PHY) that the
>> > experimental??(4.178.10.4)?firmware. causes "oom" errors.
>> > I repeated tests with both stable and experimental with the same
>> > configuration and the
>> > experimental version always caused "oom"
>> >
>> > happy to test anything else as needed. ?I currently have the stable
>> > version under a load test
>> >
>> > The following is the first "iteration" of the log - as up can see the
>> > firmware is loaded.
>> > The radio interface is added to the bridge and ?moved to the
>> > forwarding state, then POW.
>> >
>> > b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>> > b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>> > device wlan0 entered promiscuous mode
>> > br-lan: port 2(wlan0) entering forwarding state
>> > hotplug2 invoked oom-killer: gfp_mask=0x80d0, order=0, oom_adj=0
>>
>> Thanks for your tests!
>>
>> I really need some help now. Does anyone have idea how changing
>> firmware can cause out of memory on host? I try to imagine some
>> reasons...
>> 1) We detect some problem with hw/fw (correctly or not) and go into
>> some infinity recursion
>> 2) Newer firmware does sth differently with DMA, we allocate too much?
>> OK, there is not even point "3" from me. I have no more ideas :|
>>
>> I could check than new vs. old firmware on my only LP-PHY, but how can
>> I check for memory allocated by module? lsmod displays column "size"
>> but I don't think it's about memory.
>>
>
> I did look in the source and found that there where 3 locations that
> kmalloc() was called,
> I added a printk(KERN_CRIT), just before each so I could determine so
> that it would be displayed on the console.
> But I didn't get anything. ?So it must be in a tight loop. ?And I'm
> pretty sure that it is triggered by a packet being sent to the radio
> from the bridge.
> I did notice that there was some debug options so I will have a look
> at that tomorrow.

I rebuild with CONFIG_B43_DEBUG
besides creating the debugfs nothing else was displayed.
Unfortunately the debugfs is not accessible once its crashed.

----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------

Switching to 4.174.64.19 firmware for G-PHY cards?

[Rafał Miłecki]

W dniu 2 marca 2011 04:30 u?ytkownik chris at martin.cc <chris@martin.cc> napisa?:
> 2011/3/2 chris at martin.cc <chris@martin.cc>
>>
>> As one of the people why reported some of these issues, I am going to take it upon my self to
>> test the current b43 firmware with an ASUS WL500pv2. ?This uses the Broadcom 5354 SoC and > has a LP-PHY with Both the stable(4.150.10.5) and experimental?(4.178.10.4)?firmware.
>
> OK. ?I managed that faster that I expected
> I tested the latest (fresh checkout) of OpenWrt backfire 10.03
> I can confirm that when using the broadcom 5354 SoC (LP-PHY) that the
> experimental??(4.178.10.4)?firmware. causes "oom" errors.
> I repeated tests with both stable and experimental with the same
> configuration and the
> experimental version always caused "oom"
>
> happy to test anything else as needed. ?I currently have the stable
> version under a load test
>
> The following is the first "iteration" of the log - as up can see the
> firmware is loaded.
> The radio interface is added to the bridge and ?moved to the
> forwarding state, then POW.
>
> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)

Did you brought interface up, then down, then again up? I try to check
if there is reason for loading firmware twice.

Did you get the same messages with old (stable) firmware?

-- 
Rafa?

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/2 Rafa? Mi?ecki <zajec5@gmail.com>:
>> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
>
> Did you brought interface up, then down, then again up? I try to check
> if there is reason for loading firmware twice.
>
> Did you get the same messages with old (stable) firmware?
>

No, not deliberately, it is done by the network start script, so it may.
It does the same when I us the "Stable" version.
Tomorrow I will manually bring up the interface and add it to the bridge.

----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------

Switching to 4.174.64.19 firmware for G-PHY cards?

[chris at martin.cc]

2011/3/2 chris at martin.cc <chris@martin.cc>
>
> 2011/3/2 Rafa? Mi?ecki <zajec5@gmail.com>:
> >> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> >> b43-phy0: Loading firmware version 478.104 (2008-07-01 00:50:23)
> >
> > Did you brought interface up, then down, then again up? I try to check
> > if there is reason for loading firmware twice.
> >
> > Did you get the same messages with old (stable) firmware?
> >
>
> No, not deliberately, it is done by the network start script, so it may.
> It does the same when I us the "Stable" version.
> Tomorrow I will manually bring up the interface and add it to the bridge.

I have had a look at the script. and it appear that the interface is
brought up twice.
The first time to test that it is there and perform some configuration
against it.
The second time when it is passed to hostapd - looks like it resets the device.

----------------------------------------------------------
Chris Martin
m: +61 419 812 371
----------------------------------------------------------