2011/3/2 Rafał Miłecki <[email protected]> > > W dniu 2 marca 2011 04:30 użytkownik [email protected] <[email protected]> > napisał: > > 2011/3/2 [email protected] <[email protected]> > >> > >> 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 ---------------------------------------------------------- _______________________________________________ b43-dev mailing list [email protected] http://lists.infradead.org/mailman/listinfo/b43-dev
