2011/3/2 [email protected] <[email protected]>: > 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.
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 ---------------------------------------------------------- _______________________________________________ b43-dev mailing list [email protected] http://lists.infradead.org/mailman/listinfo/b43-dev
