On Jan 29, 2009, at 6:48 PM, Larry Finger wrote: > Francesco, > > Opensource firmware 5.1 works with my BCM4318; however, under heavy > load with a ping running in one window and 10 second bursts of tcpperf > transmissions in another, the kernel (2.6.29-rc2-wl) panicked by > hitting the BUG at drivers/.../b43/dma.c:1386, which is in routine > b43_dma_handle_txstatus. The specific condition is !meta->skb. > > No other messages made it to the log. I will investigate the kind of > debugging aids that Michael mentioned and send more info when > available. > > Larry
Larry, we just finished a couple of stressing tests and everything went fine, kernel did not complain about anything, below is attached the tests description. Just a few questions - have you applied any recent patch to the kernel (we too are using 2.6.29-rc2-wl), so that your kernel can behave differently than ours? - are you sure you are using the correct initvals files? Those we put today on the website? - have you replaced _all_ the files, including shm.inc etc? Here we redefined the txheader layout and moved the cookie address - are you modprobing by setting qos=0? - is your card a PCCARD or PCI? The strange thing is that the way b43 is interfaced to the firmware, when hw encryption is not activated, does not change switching from 351 to 410 version apart for the txheader layout: however we modified that layout according to definitions in xmit.h. Is this correct? If this hold I really can not understand why r5.1 had problems and r5.0 not in your setup. I would have supposed that given r5.1 has problems, the same can arise also on r5.0. Thanks, -FG Tests description: we did the following couple of tests - downloaded 1GB through TCP while sending 1.6GB of UDP like traffic through a raw socket, 10 ping/s - sent 10GBYTE by injecting packets composed in userspace through a ioctl we attached to mac80211 stack: packets are sent one after another without ACKs, separated by just a SIFS and encoded at 54Mb/s (this is a very small firmware hack that reprograms next transmission opportunity when you want, in this case just after the SIFS and only for frames sent to one not existing MAC addresses, so that no ack is sent by no one). Actual packets transmission verified by sniffing the channel by using another Broadcom card _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
