On 22 September 2016 at 14:24, Rafał Miłecki <zaj...@gmail.com> wrote: > On 09/22/2016 01:59 PM, Rafał Miłecki wrote: >> >> And again... >> >> I decided to focus on brcmf_flowring_delete a bit more. >> >> As I can see flowrings are created and removed from time to time, in most >> cases >> they are empty when being deleted. When they are not, things go wrong. In >> below >> log you can see brcmfmac removing flowring that got 8 skb packets. >> >> First some summary, of what was already partially noticed in previous >> e-mail: >> 1) brcmf_flowring_delete calls brcmu_pkt_buf_free_skb directly bypassing >> brcmf_txfinalize. It means tracing 802.1x packets and counting TX >> errors is >> broken. >> 2) After freeing skb (as the result of brcmf_flowring_delete) there will >> still >> an IRQ, MSGBUF_TYPE_TX_STATUS and call to the brcmf_txfinalize. That's >> definitely unexpected as brcmf_txfinalize will be operating on skb that >> was >> already freed. >> >> Now, there is something new that looks even worse. Sometimes >> brcmf_txfinalize >> may be called multiple times for the same skb! Take a close look at my >> log. >> It was called twice for skb c64a5a80. Twice for c64a5480. Twice for >> c64a5f00. >> Then Linux/device rebooted itself due to amount of console messages. > > > I got the same problem again, but this time there was only 1 skb in my > flowring. > That resulted in less serial console messages and no reboot. > > It doesn't look good. brcmf_txfinalize was called 11 times after deleting > flowring. Everytime it was working with the same skb that was already freed.
I'm wondering if there is some bug in flowring code. Please take a look if my following understanding it correct. 1) Every skb that is supposed to reach the device gets queued on a flowring. 2) Dequeuing means skb is not available in a flowring anymore 3a) brcmf_msgbuf_txflow dequeues skbs to pass them to the firmware 3b) brcmf_flowring_delete dequeues skbs to delete (free) them If that simple description is correct, it shouldn't be possible to skb to: 1) Reach the firmware *and* 2) Get freed as part of flowring deletion But this is what seems to be happening in my case. We get one skb freed on flowring deletion and then reported as transmitted (sometimes multiple times) by the firmware. Maybe there is simply a race between brcmf_flowring_delete and brcmf_msgbuf_txflow?
