On Thursday 14 Mar 2013 21:39:56 Chris Vine wrote: > On Thu, 14 Mar 2013 14:08:33 +0100 > > ISE Development <isedev@xxxxxxxxx> wrote: > > On Wednesday 13 Mar 2013 21:37:52 Larry Finger wrote: > > > On 03/13/2013 08:06 PM, ISE Development wrote: > > > > I've hacked the driver to 'skip' one header and data frame if > > > > receiving an interrupt for the first slot + 2. It's not pretty > > > > and I have literally no idea if it will causes other problems, > > > > but it has allowed me to keep the Wifi connection up for a little > > > > over 3 hours now (as compared to the 45 seconds previously). It > > > > does not appear to be corrupting the data stream (checked by > > > > download large signed binaries and verifying the signature) and > > > > as far as my limited knowledge can tell, it should not be causing > > > > a memory leak. > > > > > > > > The patch is listed below, for reference. However, I do not claim > > > > that it is valid, safe or even reasonsable. It does provide me > > > > with much needed relief though. > > > > > > > > The diff is against the current head of > > > > linville/wireless-testing.git > > > > (d41d9c7419e3ac9c81841f43bbd7639dd0a5819e). > > > > > > I am testing the patch on BCM4312 and other cards. > > > > > > Larry > > > > Here's a slighted cleaner version, with comments, in case you are > > considering integrating it. > > [snip] > > It might look like a bit of a hack (probably one that broadcom have > hidden away in their own wl driver if it is a firmware issue) but it is > certainly effective. > > I have applied this patch to the 3.8.2 kernel and for the first time I > get reliable performance from the bcm4312 card in my netbook using the > b43 driver. I have banged about 5 GB through it and I am continuing to > do so, but it is still up. I get I would say on average about one TX > ring error (on ring 1 in the case of my card) per 500 MB of > throughput and the frame skip resolves the problem for me. > > As this patch also avoid spamming the debug log with shed loads of > error reports once an inconsistency arises, it also reveals that the > inconsistency always begins with an expected status report of 138 and a > report of 140 being received. Yours, however, may well be different, > and this may be meaningless anyway. > > Chris Same symptom here: starts with a miss on 138 (or less frequently on 208). -- -- isedev -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
