BCM4312 / b43 DMA transmission sequence errors

[ISE Development]

On Thursday 14 Mar 2013 21:39:56 Chris Vine wrote:
> On Thu, 14 Mar 2013 14:08:33 +0100
> 
> ISE Development <isedev at gmail.com> 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