On Monday 23 February 2009 07:30:13 Larry Finger wrote: > Francesco Gringoli wrote: > > > > do you mind testing this firmware? It's not the solution, but can help > > us understanding if we should follow this way. Download at > > http://www.ing.unibs.it/~gringoli/fwtest.tar.gz > > > > Before using this firmware please recompile b43 changing these two > > definitions in b43.h > > > > #define B43_MARKER_ID_REG 52 > > #define B43_MARKER_LINE_REG 53 > > > > I coded the firmware so that it will raise a B43_DEBUGIRQ_MARKER with id > > 10, line 100 if the condition I'm thinking to is true. You will see (I > > hope) in dmesg. > > I ran the test firmware until there was a failure. The B43_DEBUGIRQ_MARKER was > not present in the dmesg output. > > I also did as Michael suggested and preserved the depth of the tx_status > queue, > as well as the maximum depth observed. The latter value is 16; therefore, it > is > possible that the queue is being overrun. It is certainly full if the limit > really is 16. I still need to look at the detailed data from the last run, but > it is late here today.
Note again that I expect the "tx status queue is full" check at the _start_ of the TX processing in firmware. Because if we started TX and later figure out the status queue is full, we can't really do anything about it. So we'd have to check that before even fetching the frame from the DMA. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
