Hi Willy On Wed, 7 Apr 2021 at 17:42, Willy Tarreau <w...@1wt.eu> wrote: > > There are two new status bits TBNQ and FBNQ at bits 7 and 8. I have no > > idea what they mean. > > Maybe they're related to tx queue empty / tx queue full. Just guessing. > Since all these bits tend not to be reset until written to, I got confused > a few times trying to understand what they indicated.
In the vendor driver they have some weird logic that counts idle, bnq, and these 6 new bits, and if the count of set bits is bigger than 5 it's apparently OK to setup another frame to send. I guess it's some really optimized form of checking for the right flags but it's over my head. :D You have to check it's OK to send right before setting the frame address/length otherwise you will get an overflow eventually. So I think some of these bits are related to the state machine that is handling popping frames out of the FIFO and the bits might change between getting a TX complete interrupt and trying to queue another frame. i.e. you can have a situation where there seems to be a free slot in the irq handler but it's not actually safe to queue it when xmit is called, and if you do an overflow happens and the TX locks up. > > Anyhow. I'm working on a version of your patch that should work with > > both the at91rm9200 and the MSC313E. > > Cool! Thanks for letting me know. If you need me to run some test, let > me know (just don't expect too short latency these days but I definitely > will test). I got this working really well last night. 10+ hours with the iperf3 bidir test and it's still going. Before TX locked up within a few seconds. Once I've cleaned it up a bit more I'll push it to my mstar tree. I don't think it can be mainlined yet as it's not usable without a bunch of other bits. Cheers, Daniel
